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