>>It could also break some code relying on Scan NOT restoring the record pointer.
>
>Wouldn't it be some bad design or some bad use of the SCAN functionality? :) Yes, I also thought about the same. But, to me, someone who uses SCAN should SCAN as per the SCAN condition.

Right - but then recursive scan wasn't in the original spec either. Still, we've seen two good ways to do it.

>>This is the way it worked ever since Scan was introduced. Alternately, you could do what Sergey meant:
>
>The problem with that is that would open too much new aliases. Basically, what I did by restoring the pointer is the best way in my situation.

Yes, it would open one alias per level; depending how deep your structure goes it may or may not be too much. One thing I know is that this becomes too slow (I've seen it done with a SQL select into a new cursor each level, then check if any records were selected), so my favorite technique was to build a key which would order the table into its proper tree order. It only took one rebuild for each save, and worked fine for the intended use (reports dictionary, with very few changes over time). Next time the table was simply open ordered by this key and scanned in a single linear pass.