Geo,

>First, LOCATE does require an optimizable expression in the FOR clause to kick in Rushmore. Without it, it has to do a sequential search.

Obviously.

>Further, since LOCATE supports a CONTINUE to find the next match, it has examine then next record and any thereafter, indicating a sequential search.

But a sequential search of the table only if not optimizable, I'd think. If optimizable, I expect that it's just stepping to the next match in the Rushmore index bitmap.

>Again, it appears from the results, that many more comparison in the cases with LOCATE must be taking place.

Seek should just center in on the first matching record it finds, where optimizable LOCATE probably builds a Rushmore index bitmap of all the matches, much as a SELECT would do. That might explain the extra time for optimized LOCATE.

In your example, was there only 1 matching record, or several? I don't have time for testing now, but it would be interesting to check it in a very large table with only 1 matching record, then with several matches.

Anyway, my point was just to challenge the statement that LOCATE is a sequential search of the table, since it isn't necessarily that when optimized.