Mike,
I ran your tests with my table and the results concur with yours. Your reasoning makes sense in that if you seek a record with an index that's not very "selective" (thanks for the word, Walter), the difference between locate and seek is even greater. If you add an index on DELETED(), the difference is greater still. We know that the LOCATE sets aside the pointers for the CONTINUE since it does not "see" records that "should" be found, if they are added by other users subsequent to the LOCATE and prior to the CONTINUE.
To sumarize:
With a highly selective index, like a primary key, SEEK() is better.
With an index of low selectivity, SEEK() is much better.
With an index on DELETED() and SET DELETED ON, SEEK() is much, much better.
However, it's as you say. "Seek is for finding a single record, locate/continue and SQL are for finding a set of records."
Charlie

>All of this is speculation, but its just not that simple. Determining which index tag to use shouldn't account for that much delay. I only had one index in my little test program. The number of records is what caused the delay. Rushmore (in the LOCATE) is paving the way for a probable CONTINUE. Rushmore is paving the way for quick access of the records that meet the condition. This involves recording a list of records that met the condition and that would account for the delay increase with the number of records.
>
>I should probably now refer you to Foxpro Advisor September 1996, and my own article in Foxpro Advisor July 1997. These articles operate on the premise that Rushmore is doing a lot more than a seek does.
>
>Regardless, the point is that seek is way faster than locate in simple tests because the two search techniques are vastly different. There should not be any question which to use. Seek is for finding a single record, locate/continue and SQL are for finding a set of records.