>>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.