Jim's compound example is the one reason I can see for using Locate. Otherwise, I would use Seek...

>I use LOCATE all the time. In my epxerience, except when you are in a tight loop, LOCATE is not noticeably slower than SEEK(). The additional performance hit comes only in the time it takes VFP to decide which (if any) index to use, and that time is small. When it doesn't have to be done over and over, you can't really tell a difference.
>
>I also use it all the time for the reason Jim brought up, and one more too- if I need to find a record, I have no idea whether the expression has an index or not. It might, it might not, and if it doesn't now, it might in the future, and vice-versa. In performace tuning, indexes sometimes come and go, even though there might be existing code that needs to find a record based on that criteria. With LOCATE, I can count on VFP to decide for me. Its also very valuable in a generic utility type program that doesn't know, and doesn't care if the expression being searched is optimizable.
>
>
>>Sure... Then again, in many cases, this will be partially optimizable, and you will still get a big bang for the buck.
>>
>>Good example!!
>>
>>>>First off, I am not sure why we are even discussing Locate. Unless we are talking about a non-indexed field, it has NO value. Best to use Seek.
>>>
>>>John,
>>>
>>>Another place where LOCATE is of value is when the criteria is complex and there is no particular index that would allow a seek;
>>>
>>>LOCATE FOR State = "PA" AND Amount >= 1000 AND Amount <= 10000
>>>
>>>There may be indexes on State and Amount, but there is no way to SEEK that criteria.