Craig,

>>IMO, This is not correct, If my memory serves well, someone already proved that seek was way faster than locate for other reasons (Mike yearwood ?). If the table grows larger, so does the difference in performance between the two. This can't be explaind only by 'determining the proper indexes to use'
>
>I've never heard of this being done, but would be interested in seeing it.

I think you've got to read Thread #253099 Message #253203 and further. In this thread I take the exact same standpiont you do here. It turned out to be that Mike yearwood was right all along. You'll find a few references to FPA articles which explain the rushmore working.

>>You're correct that locate has the overhead of determining the index tag(s) to use (therefore it might be wise to drop indexes for small tables or turn optimization off). But after it has done this it makes a bitmap of all matching nodes of all matching tags. In most cases you won't need the other indexnodes loaded into memory because you're probably interested in only one record (else you'd rather go for SCAN) and won't use the CONTINUE statement regulary.
>
>But the bitmap may not be in memory when you need it, therefore forcing it to be recreated.

The bitmap HAS to be in memory because rushmore won't work when it's not. (not enough memory for optimization warning).

Walter,