But the less records you process, the better rushmore performs, so REST WHILE FOR has to be faster than FOR.

Let´s agree on this: Regardless of performance, VFP failed!.

>Your argument may be valid, but the way I suggested is the way I would do it in any case since it can take advantage of Rushmore which should be very fast.
>
>Bill
>
>>Yes, it worked; but the point here is that I don´t want to go through all the table when I can just check a few records.
>>More than it, VFP MUST have worked fine, we're not supossed to be investigating wether an instruccion works or not before we use it. For the very first time, VFP has deceived me.
>>
>>>>I used this:
>>>>select mytable
>>>>set order to mycode
>>>>seek (mycode)
>>>>myvar = ""
>>>>Calculate max(myfield) to myvar rest while code = mycode for myFilterCondition
>>>>
>>>>It works fine ONLY if there are matching records to myFilterCondition.
>>>>
>>>>If no records within the scope match myFilterCondition, myvar returns a value from myfield on the next record out of the scope (this is, where code # mycode).
>>>>
>>>>I expected myvar to be blank when no matching records, even if it wasn´t blank before the calculation and much more if it was blanked as shown upthere.
>>>>
>>>>Is this a bug of vfp?. Does this work as I expected in other versions of Vfp? (I´m running VFP 6.0 version number 06.00.8167.00)
>>>
>>>Have you tried something like:
>>>
>>>

>>>MyVar = 0
>>>SELECT MyTable
>>>CALCULATE MAX( MyField ) TO MyVar FOR ( code = MyCode AND MyFilterCondition )
>>>

>>>
>>>Bill