Larry,

Thanks for your replies. I could create an unbuffered table as you suggest that contains the nodes and the PK, but I still need them on the other table. At this point though, I think I will either do what you suggest or create an array with node and PK and use ASORT. I wonder which one would be faster.

Live from Florida, the undecisive state...


>I'm a little slow today (up too late watching election results which didn't do me any good anyway).
>
>Can the tree structure be broken out from the actual table? It sounds as though there is an extra field in the table that acts as the node key. Can you create a node table with the PK (or record number) of the record in question as well as the value that you want to sort. This node table would be unbuffered. As it would be a temporary cursor, you could have it exclusively for that matter. You could perform any SQL select on this node table you needed. During your processing, you could update the buffered table as needed. SEEK does work on a buffered table so finding the target record given the PK should not be a problem.
>
>>Well, the reason I need to perform my pre-save check on a sorted table is because this table is a tree structure. In order to perform the checks that I want, I need to follow the tree structure using a node notation stored in one of the fields. Actually there is more than just checks, it actually replaces some values on some branches, based on the values of other branches (records). That is why I need them to be in sorted order. As you said, I could save the table to a temporary table and then index it then, but that is more overhead than what I was hoping. Another way would be to do a bubble sort on an array, but that is also more overhead than what I was hoping. However, if there is no way to re-sort (or re-select) from a table in memory, I might have to opt for one of those options....
>>
>*snip*