Hi Hugo,

Thank a lot for the interest. I'm also having hard time to understand the code (it was written before me). The idea is to save the current state of the tree in the ItemTree table.

The user may add some new values to any of the branches, may re-order items in any of the branches, may insert a sub-tree, may delete nodes (or even sub-tree nodes), etc.

I was testing the simplest scenario yesterday. In a tree with several sub-trees I deleted one last node in one of the sub-tree. As I understand and expect, it should not change any ordering of the tree as each branch has its own ordering relative to the parent. Yet all top-level branches were re-ordered.

So, the current algorithm has a bug. I can post a SaveChild method (this is where the problem seems to occur) and also a picture of the tree.

Or, if you have some time, we can discuss this in private as I really need some help here and hope you can be of invaluable help.

>Naomi,
>
>I do not understand the algorithm at all, I do not know what this code is trying to accomplish, but what about working more with the data, wouldn't it be faster?, for example at the beginning you have
>
>

>* Find a root node in the TreeView
>	oTree = .TList2
>	if oTree.Nodes.count > 0
>		for i = 1 to oTree.Nodes.count
>			oTmp = oTree.Nodes(i).parent
>			if isnull(oTmp) then
>				iTmpIndex = i
>				exit
>			endif
>		next i
>

>
>Which finds only one of the possible multiple root nodes of the treeview, wouldn't be faster to do
>
>

>select node_id from ItemTree where parent_id is null into cursor c_roots...
>

>
>You might even be able to avoid the next step, finding the sibling if you use order by sort_order, I think. Anyways, what I am trying to say is that maybe it is better to work with a mix of data instead of just scanning the tree which might be expensive.