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

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

David,

I was speaking strictly in the worst case scenario. The worst case for LOCATE is no index matching the criteria. In the worst case it is a sequential search.