>>>I want to add my $.02 here.
>>>
>>>LOCATE deninitely IS Rushmore Optimizable. If a matching index exists, the query is NOT sequential.
>>>
>>>If possible, the queried table should not be ordered when LOCATE is issued. Even if the table is ordered on the index that Rushmore will use to optimize the query, it will inhibit the search. BTW, the same applies to SQL queries.
>>>
>>>The performance of a single LOCATE search is roughly the same as that of a SEEK. The slowest part of the search is the time it takes to open the index. This is where SEEK has an advantage over LOCATE. If the index you want to use is already open (or you want to lookup several records using the same index), then SEEK will be faster than LOCATE. Otherwise, LOCATE will be just as fast as SEEK.
>>
>>Well, using your code, SEEK, over 10 iterations was an average of more than 250% faster. When the code clearing the index was removed, it was over 280% faster, and when opening the index was removed, it was more that 410% faster.
>
>George,
>
>There's obviously someting else going on here. I just retested my code a dozen or so times. The results are consistently around 4 seconds for both LOCATE and SEEK.

Brien,

I just re-tested another six time with the same results. The only modification to your code that I made was the addition of an additional FOR...NEXT and variables to hold the totals. Again, the average was SEEK was more than 250% faster than LOCATE, with the average being around 1.25 for LOCATE and .50 for SEEK. Tests were conducted using VFP 6.0 SP4 on PII 350 with 128 mb of RAM. The cursor created was on the local drive.