Yes, I know what Rushmore is and what is optimizable and what not. I was talking about non-optimizable database operations. (Read: tests done with SET OPTIMIZE OFF and also non optimizable expressions.)

Vlad

>Vlad,
>
>Citing the Developer's Guide, page 400 in Chapter 15 "Optimizing Applications" (VFP 5.0 edition):
>
>Under "Operating without Rushmore". . .
>
>" Data retrieval operations proceed without Rushmore optimization in the following situations:
> * da-da-da. . .
> * When a command that might benefit from Rushmore contains a WHILE clause.
> * da-da-da. . . "
>
>Maybe I'm misreading what WHILE you are using, and where you plan to use it, but I think the quote is REAL clear as regards otherwise optimizeable commands.
>
>Cheers,
>Jim N
>
>>Not if the percentage of scanned records is high. This is because of the way data is cached (is this a correct word in English? :)). (This is the only explanation I found.)
>>
>>Also, if you SCAN FOR ... ENDSCAN the same table ordered and not ordered, the not ordered SCAN is much faster. (I obtained up to 1:21 raport on a Novell netware.) Since the WHILE scans a great part of the table, it is almost the same as the FOR. (It's hard to beat a 1:20 rapport! :))
>>
>>This applies only when the order is random compared with the physical order. But this the usual case, so...
>>
>>The best thing is to do your tests in each real situation. Because if the order (almost) matches the physical order, the WHILE is faster in all cases.
>>
>>Vlad
>>
>>>Vlad,
>>>
>>>Since the table is ordered, and the record pointer is positioned at the first applicable record, wouldn't
>>>
>>>SCAN REST WHILE...ENDSCAN
>>>
>>>be faster regardless of the percentage of records?
>>>
>>>George