>This is correct when your searching for a unique record (there is only one matching record). But when you're searching for an expression which matches more than one record, it will become more likely that the first candidate will be more to the front of the file, which means that the avarage time of a non-optimizable LOCATE will drop significantly.
>
>OTOH if you are using the LOCATE to check if a record does exist, rushmore is likely to be the winner as it can detemine quite quickly if a matching record does exist.

I'm missing something here, are you saying that in this
case an optimizable LOCATE would be faster than a
SEEK?

>I think there are lot's of factors involved which determins which is faster; to name a few which probably are:
>- The selectivity of the optimizable part of the FOR clause
>- If the indexes are balanced

Walter would you comment on these two items. I'm
not familar with the terms "selectivity" and
"balanced index".

>- The existance of NON - optimizable parts of the FOR clause

NOT DELETED() for instance?

>As a result I can only conclude, you've got to test if rushmore is helpfull or not in your case. I do step off the idea that there is a general rule of thumb; it simply depends on too many factor IMO.

One more thing. Outside of having the code right
there in front of you, how would one confirm the behavior
of index processing (i.e. whether it reads the whole index
and scans it sequentially)?

...kt