• sarwaanmca (12/30/2012)


    Hi Sunil ,

    The Required Heirarchy is,

    [ CEO ]

    1 -> President QA

    ->-> VP QA

    ->->-> Team Lead Team1

    ->->->-> Senior QA

    ->->-> Team Lead Team2

    2 -> President Dev Dept

    ->-> VP Dev Dept

    ->->-> Team Lead Team1

    ->->->-> Senior Dev

    ->->-> Team Lead Team2

    ->->->-> Senior Dev

    ->->->-> Senior Dev

    Pls Try this one...

    Thanks & Regards,

    Saravanan

    Even with the nicely laid out structure you have above, there is no way that the current data you've provided will support identifying whether someone with the position of "Senior Dev" should be a member of the "Team lead Team1" node or the "Team Lead Team2" node.

    Your data needs a "PositionID" and a "ParentPositionID" column to do this task consistently. Please check your original table and see if such things are available. If they aren't, then your team will need to add them either directly to the table or as a sister table. If that can't be done, this project is doomed to failure.

    An even more effective alternative to PositionID would be to have EmployeeID (or some such) and a ParentEmployeeID column.

    In either case, the PositionID or the EmployeeID must be a unique number to support this task properly.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)