>>IIRC, once upon a time we had some theoretical explanation for the behavior of Locate: it builds a bit map of records that it finds. Depending on the size of the table, the physical layout of these records in the table etc, this map may take some time to build - but then a loop with do while found() and a Continue before the end of the loop would be blazingly fast.
>>
>>Being spoiled by Scan/Endscan's elegance, I haven't tried this ever since. The Locate/Continue looks somewhat clumsy, compared with Scan/Endscan, so it seems I'm avoiding it. Maybe I shouldn't... but I just don't think in that direction.
>
>From Rushmore's perspective only SCAN+ENDSCAN = LOCATE+CONTINUE # SQL

I'm also considering the coding side of it - the need to be on the right alias when issuing the Continue command, the possibility that some code may creep in between the Continue and EndDo etc... Scan/Endscan is simpler and more elegant.

>SEEK first is often faster, but you cannot build a system only using seek and then make that work with a different backend. I prefer one approach. For me, Seek is relegated to incremental searches in SQL generated cursors and indexes are only to show the SQL generated cursors in different orders.

I don't really believe anything can be done using just one approach - it changes from situation to situation. IOW, of course I wouldn't build a system using only seek, when I have so many other tools at hand.

For situations when you have one long cursor, containing many documents, and you need to do something with records belonging to one document - and do that in a loop for a dozen or few hundred documents, you have two ways, again depending on what exactly you need to do. One is to grind that long cursor into a shorter one with one record per document, using a select...group by. When that's not practical (you need to do only a few documents, you need to do something for which there's no aggregate function, or you need to update the long table in a few places), you can do a seek+scan while, which will give you the speed and flexibility - you'll have to (and be able to) write your own code to aggregate data at document level. So, again, it may be much faster and simpler (read: faster in programmer time, and maybe runtime) to write a loop than to get into an "but can you do this in one SQL?" exercise. It all depends, from case to case. Sometimes I'll gladly wipe out the whole loop and write a SQL six-liner instead.

>>>seek()+locate while however works fast. Hope it is clear now.
>>
>>Still haven't found anything that beats "seek+scan while"'s speed.
>
>seek + locate while = seek + scan while from Rushmore's perspective.

I.e. it builds a bitmap of records to visit, and then just uses it via different syntax.