Dragan,

>>Walter,
>>
>>>Hi doug,
>>>
>>>>I don't have any problems with that approach. I just seem to remember that the SEEK + DO WHILE combination is supposed to be a little quicker. Haven't tested it myself so I may be incorrect and I suppose in the long run it's not a real big deal.
>>>
>>>SCAN WHILE should at least as fast as DO WHILE (I've not tested it either). Since SCAN WHILE automaticly skips through the table (as oposed to DO WHILE ... SKIP) it is my favourite. I think you were confused with SCAN FOR, which indeed is slower because it is rushmore optimizable (sounds weird doesn't it ?) SCAN WHILE is not rushmore aware and just skips through a table like DO WHILE ... SKIP.
>>
>>Hmm.. Probbaly so. That is, confused. <g>
>
>To add to the many ways you can skin the... fox, I sometimes do
>Seek cValue
>Scan rest for {condition} (plus optional While cValue=keyField)
>This seems to be faster than plain Scan For, because the first Seek finds the block of index where the subsequent keys are, and the record it belongs to - which is a minimal number of blocks compared to other ways (that's why Walter says "faster because it's not optimized", meaning "it doesn't need to read the whole index"). With the records already at hand, and most probably a good number of subsequent index entries already in the buffers, it's a good candidate to be faster than Scan For, and even faster than Select ... where cValue=keyField and {condition}.
>
>I was using this on large and heavily indexed tables, where Rushmore is good if you want to pull some composite data, run totals or a general query, but in cases when you need to access a bunch of records down one of the existing tags, this was simply faster, because it extracts less sweat from the network.

I think the 'trick' here that gives the improvement in speed is the business of not pulling the whole index over the wire.

Interesting discussion...