All I wanted to say is that there are situations when a SCAN FOR on a not ordered table can be faster than SCAN WHILE on an ordered table. You're right, I should have say that this is not optimized. As I already said today in an other message, test for yourself for each given situation and choose the best solution you find. In the tests that can be made, is the one I said: SCAN FOR no order vs. SCAN WHILE with order. Sometimes the result is not the one you might think it will be.
Obviously, an optimized SCAN FOR is faster than a not optimized SCAN FOR. Also, an optimized SCAN FOR is not necessarily faster than a SCAN WHILE.

What is really important: I don't know why, but there are a lot of programmers who think that is enough to have optimizable expressions in order to have the best speed. This is not true. The current set order is very important and no order is best, when possible. And this is true regardless of Rushmore.

I think that anyone interested already got the idea and will try it. Sometimes they will get better results because of this and this is the whole point here.

Now, please notice that English is not my mother tongue. I know I still have a lot to learn and I'm trying to improve it everyday. It's very possible that I want to say something, but what I really say means something different in English. I am sorry for this. It happens now and it will happen in the future. So, everytime you don't understand what I want to say, either (if you're interested) ask me and I will try to explain in a different way or I will accept I was wrong or just ignore it (if you're not interested).

Vlad

>But I guess I should have known that YOU can make super fast response with OPTIMIZE=OFF! How stupid (utterly!) of me.
>
>Best I just keep quiet on your messages from now on.
>
>Jim N
>
>>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