No argument there. It's just that going to the end of the table is REAL fast if it is properly optimized. SKIP -1, which is not optimized, may still be faster because it probably has less records to scan through.

Like I said, I have not benchmarked this but it seems to me like that is the way it should work out most of the time.

Menachem

>Hi Menachem
>
>LOCATE FOR condition will land on the first record that matches the condition. If the condition never becomes true, VFP ends up on the EOF record. Since the condition you suggest is .F. which can never be .T., unless you're into quantum mechanics or illicit drugs ;), it will only ever end up on the EOF record. I tried with several tables, but couldn't find a way around it. ;) If it ever did work, I think they fixed that bug! :)
>
>>Did you test this? I am not sure that is necessarily so. It certainly could be true depending on how the data is laid out.
>>
>>How many rows in the table? Are you sure you want to do it this way?
>>
>>>
>>>LOCATE FOR .F.
>>>
>>>
>>>This send me to the EOF() condition,
>>>then i must use a SKIP -1 for go into the last unfiltered record,
>>>but SKIP -1 is not optimizable, and then:
>>>
>>>speed of not optimized
>>>

>>>GO BOTTOM
>>>

>>>
>>>is faster of
>>>

>>>LOCATE FOR .F. && this is optimized
>>>SKIP -1        && this do a back scan loop
>>>

>>>
>>>Thanks
>>>
>>>Fabio