Well SSOOORRRRRRYYYYYYYY!!!!

It just seems to me that virtually EVERYBODY in this place who talks about performance IMPLIES Rushmore, whether it is STATED or not.

Forgive me for ASSUMING that you too were also talking about Rushmore.

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