I want to add my $.02 here.

LOCATE deninitely IS Rushmore Optimizable. If a matching index exists, the query is NOT sequential.

If possible, the queried table should not be ordered when LOCATE is issued. Even if the table is ordered on the index that Rushmore will use to optimize the query, it will inhibit the search. BTW, the same applies to SQL queries.

The performance of a single LOCATE search is roughly the same as that of a SEEK. The slowest part of the search is the time it takes to open the index. This is where SEEK has an advantage over LOCATE. If the index you want to use is already open (or you want to lookup several records using the same index), then SEEK will be faster than LOCATE. Otherwise, LOCATE will be just as fast as SEEK.

I tested this with the following code:

IF !USED("test")
  CREATE CURSOR test (pid i)
  INDEX ON pid TAG pid
  FOR lni = 1 TO 1000
    INSERT INTO test VALUE (lni)
  ENDFOR
ENDIF

SET ORDER TO
lntime = SECONDS()
FOR lni = 1 TO 10000
  LOCATE FOR pid = 699
ENDFOR
lnlocate = SECONDS() - lntime

SET ORDER TO pid
lntime = SECONDS()
FOR lni = 1 TO 10000
  SET ORDER TO pid
  SEEK(699)
  SET ORDER TO
ENDFOR
lnseek = SECONDS() - lntime
WAIT WINDOW "Locate took " + TRAN(lnlocate) + " seconds and seek took " + TRAN(lnseek) + " seconds."

>Mike,
>
>>>>Anyway, my point was just to challenge the statement that LOCATE is a sequential search of the table, since it isn't necessarily that when optimized.<<
>>
>>This might be an exercise in semantics, but if a bitmap is how Rushmore works, the position of the bits probably correspond to record #'s. So, it may be that LOCATE is always sequential. The difference would be that VFP is sequentially passing through the bitmap instead of the table.
>
>Right.