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.