Hi Gregory,

Thanks - I got thinking along those lines after seeing Al's comment from Friday night - I think the solution #1 would be the easiest to implement. I already have a function called GetTopMostParentID() that I could modify to keep track of which parent_IDs have been processed so far and if I hit a duplicate, to trigger an error (or create a new function to do the same).

Question: what would a candidate index look like and how would I use it? Just wondering where you are going with that.

Albert

>
>(1) "related companies processor"
>The way to avoid the loop is to keep track of the ParentCoID's which you have processed so far. If you are about to process a ParentCoID that has been processed before, you are about to enter a cycle (loop)
>
>(2) It would help to have a candidate index on Company_id since an office can not be a branch (child) of more than one head office (parent)
>
>(3) To detect a potential cycle when the user changes a node. Process downwards depth first, keeping track of all the ParentCoID processed so far. If you are about to process a ParentCoID that has been processed you have a cycle
>That cycle is either a cycle that the user is about to introduce, or a cycle that was already present