Erik,

Just to clarify, SEEK is not actually Rushmore optimizable. It will use the current index. This means that in some cases LOCATE is much faster than SEEK. For example, if you have a Rushmore optimizable filter set that results in only a small fraction of the table meeting the filter condition and you do a SEEK, VFP will find the first record in the table that meets the SEEK criteria regardless of whether it meets the filter condition. It will then scan the table until it finds a record that still meets the SEEK criteria but also meets the filter criteria. This can be significantly slower than LOCATE which will use both the filter criteria and the locate criteria to find the record.

Without a filter set I find that SEEK is generally faster, probably because of the overhead involved with Rushmore.

>LOCATE and SEEK are both Rushmore optimizable, and in single uses will be nearly indistuishable as far as performance differences. If you LOCATE is slower tan your seek, it is because te expression you trying to locate for is not optimizable.
>
>The only reason that SEEK is faster than LOCATE in tight loops is that when you issue LOCATE, Rushmore has to scan the index to see if the expression you are LOCATEing for matches an existing index. When you issue a SEEK, you tell Rushmore what index to use either in a parameter or by virtue of having an order set on the table already, so the extra anlyzing effort is unneeded.
>
>I almost always use LOCATE outside of loops because it is not dependent on the existence of an index, and that's one less thing that can break. But this is just personal coding preference.
>
>BTW, the current ORDER setting on a table cannot screw up either a SEEK or a LOCATE, unless your SEEK is assuming a different index is active.