The general rule is that Rushmore is a bit faster if you SET ORDER TO before you use it. In your example of the LOCATE, you have essentially done this.
You can do a LOCATE and CONTINUE, but I do the same thing with:
SET ORDER TO MyTag
SEEK MyKey
SCAN WHILE SomeField = MyKey
ENDSCAN
SEEK will be a bit faster. This is because for Rushmore to work, all the tags must be scanned to see if an appropriate tag exists. There is a complete disucssion of Rushmore on my website.
>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
>
Craig Berntson
MCSD, Microsoft .Net MVP, Grape City Community Influencer