Keith,

The seek solution is (way) faster when using only one index to seach a record. I've seen difference in a heavy routine from 2 hours to 5 minutes when using LOCATE and SEEK respectively.

It's in the nature of rushmore which downloads all matching indexes whereas SEEK only searches trough to B-tree to find the first matching record. So SEEK does result in less network traffic.

You can enhance performance even more by filtering the index (FOR Clause, like FOR !DELETED()) for records which you don't want to search on. This way, SEEK will be even faster.

However, where using two indexes for rushmore (LOCATE FOR Field1 = Expr AND / OR Field2 = Expr) LOCATE is likely to be the winner here, though this depends on the situation.

However, if you table is less than let's say 100 records, your LOCATE will run the fastest without rushmore, so include the NOOPTIMIZE clause. The break even point, is depended on a number of factors, but a general rule of thumb I use is about 100 records.

HTH

Walter,




>Is there a rule of thumb for using Rushmore as
>opposed to Explicit indexes, i.e.
>

>SELECT Customer
>SET ORDER TO 0
>LOCATE FOR CustId = "12345"
>
>       vs.
>
>SEEK "12345" ;
>   IN Customer ;
>   ORDER CustId
>
>

>
>Both should yeild the same result (barring any
>fat finger errors on my part in the example
>above). VFP should encounter a little bit of
>overhead in determining which index to use
>(i.e. it's "strategy") but is there a minimum
>number of records that must be in the table to
>make Rushmore worth while? Is there a minimum
>number of optimizable expressions? That kinda
>thing.
>
>TIA for any feedback you guys can give me.
>
>

>
>   ...kt
>