Using an array wil lbe fairly fast. But another route along the same lines as the unbuffered table is to create a temporary table and create as many indexes on it as you need to sort them. Because the table is initially empty, index creation will be fast. In order to resort the data, just set a new order.

I suggest this instead of the array because I don't know how much data we are talking about and you may reach a limit going the array route route.

>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*