>>A good point. Also, I don't know if the control has been revised lately, but here is another trap to watch out for: by default it does a LOCATE first, then a SEEK() - which if you are working on a big table can really bite you, timewise. You might watch out for that. <
>
>LOCATE is optimized just like a seek, and in many cases it is preferable because it helps get away from the large number of compound indexes developers used to write in order to do a seek.
>
>
>---Scott.

Scoot,

A minor correction; Locate is optimized, SEEK is not optimized by Rushmore (it uses the index directly). SEEK is always faster than a LOCATE for the same value. LOCATE does not require an order be set on the table to work, in fact LOCATE is faster if there is no order set. SEEK requires that the controlling index match the SEEKed expression.

LOCATE is fast enough, in most cases, when it is fully optimizable and the expression is complex. SEEK is preferred when the expression is simple and setting the order is not a problem.