Interesting, keeping track of parent IDs already checked. It feels more "general". If you think your existing list may be "dirty" i.e. have other undetected loops, then it's definitely a better way.

OTOH if your list is otherwise known to be "clean" then I believe you only have to check whether you come back to the same CN. Let's assume you've already handled and disallowed the case where CN's parent is set to itself (although that's only a special case of [quickly] finding a parent that is CN). Then, CN's parent is another node which is previously known to be clean; the only problem you could encounter would be if you hit CN again while walking through the parents i.e. the parent of one of those is CN.

So, for safety and fault tolerance it's probably better to track all checked parent IDs. It could log or otherwise expose message(s) to the user about problems with unrelated nodes. It could also be used while processing all nodes for a health check/system maintenance process.

>Hi Al,
>
>I knew someone here would think of something - I think you have seen the holy grail through the trees (to mix metaphors/movies). I already have a function GetTopMostParent_ID that looks upwards parent by parent until it hits a parent with no parent id itself. I could modify that function or create a new one that just does a "check".
>
>Or better yet, I could write a function that also keeps an array of the parent id's as it loops upward and as soon as I hit the same parent twice, I must be in a loop.
>
>Thanks!
>
>>
>>One way to structure lists like this is to have top-level entries that have no parents. If you've done that you could "walk" through the parents of the candidate node (CN) that is about to be changed. If you eventually hit an empty parent, then OK. If you hit CN, then you have a loop and you disallow the change.