>Geo,
>
>>LOCATE is a sequential search of the table. SEEK utilizes indexes which are binary trees ordering the table.
>
>I'm not debating that SEEK is faster -- but how can LOCATE always be a sequential search of the TABLE, even when Rushmore kicks in?

First, LOCATE does require an optimizable expression in the FOR clause to kick in Rushmore. Without it, it has to do a sequential search. Further, since LOCATE supports a CONTINUE to find the next match, it has examine then next record and any thereafter, indicating a sequential search. Lastly, to demonstrate how Rushmore effects the results, consider the following results from a small test I ran. I used a table with 493 records search for the record with a key at approximately the middle of the table (both physically and in terms of the order), ran 10,000 SEEKs, and 10,000 LOCATEs both with an without the index tag set. Naturally, the expression was optimizable. The elapsed times were:

SEEK - 0.098
LOCATE (without the tag set) - 6.020 to 6.052
LOCATE (with the tag set) - 1.970 to 1.980

It would appear that, in light of the above and because the scope by default is all records, that all least the record pointer is being moved to the first record in the table in the case without the tag set. Again, it appears from the results, that many more comparison in the cases with LOCATE must be taking place.