Hi Terry,
If, as is sometimes the case, I explicitly don't want the record pointer moved then I'll just use INDEXSEEK(). It's very handy. The problem was that I believed that INDEXSEEK(..., .F.) was going to be much faster than SEEK() because it didn't move the record pointer. That turns out not to be the case if SET DELETED is ON
KEYMATCH() is faster than both, but can't distinguish deleted records, so is off limited use.

>I guess the options are:
>

>if INDEXSEEK(lcMyKey,.t.)
>   * Do the the pointer set stuff
>   * if failed - we stay at current (previous) pointer
>endif
>... or
>lnRecNo=recno()
>if seek(lcMyKey)
>   * do the record pointer stuff
>else
>   go lnRecNo && Return to previous point
>endif
>

>
>Speed issues aside:
>INDEXSEEK can tell us if a key exists, but not move the pointer, tell us if a key DOES not exist, but not move pointer - or move the pointer, should the key exist. SEEK will always move the pointer. After the very-first-runtime-point, the current pointer will always be at the current record(?)
>
>>I think we're all missing the point here.
>>
>>I contend that the benefit of INDEXSEEK is nullified in the majority of cases because we usually have SET DELETED ON. Sometimes we have a SET FILTER TO as well.
>>
>>In these cases INDEXSEEK must not only do its normal look up of the index but must also reference the data record that matches the index to check on the deleted (and/or filter) status. In this case it appears to be no faster than SEEK is.
>>
>>I provided some example code merely to indicate how someone might test this in their own case. The important point in the test code, is that it is not a fair comparison if the data (no the index) is already correctly placed in memory. In each test case I make the *same* record movements so this should allow a valid comparison, regardless of whether I use LOCATE, GO TO , GO TOP etc to do so.
>>
>>If INDEXSEEK didn't move the record pointer (or some internal equivalent) then you would expect it to outperform SEEK in every case. It doesn't. It's consistently slower in my observations than SEEK whenever SET DELETED is ON or there is a filter in effect. It is much faster than SEEK *only* where SET DELETED is OFF and there is no filter in effect.
>>
>>
>>>>It's needed because VFP has to check the data record to see if it matches the filter or is deleted. That's my point. I put the GO BOTTOM there simply to move the record pointer away from the record which has already been found in the previous loop.
>>>
>>>LOCATE is optimizable and go bottom and go top are not, so the effect of moving the pointer can be very different between these various techinques.