>Mike,
>
>>Locate reads the entire index tag, seek hops through the tag by halves as it gets to the seek value. If your tables get larger, locate will get slower and slower while seek will stay relatively fast. That's why its recommended in tight loops.
>
>Well, I doubt if this is true. I've got some clues that rushmore optimizable commands don't read the entire index tag when in the form of "FOR eExpresion".
>One of my client has a WAN 64 kbs connection. When I open a large table with a large CDX file and isue a BROWSE FOR eExpression where a certain article index tag is used, It certainly does not read the entire tag, because the result is shown within a second (the entire tag might be something like 500k, the CDX about 3 or 4 MB)
>
>That the LOCATE command is a bit slower than SEEK might have other causes, like the LOCATE Being a more complex command than seek, so it might take more time to process the command in terms of the internal C++ code.

One thing I've found is that for the first optimizable LOCATE issued, on a table with many (20 or 30) tags, there sometimes is a distinct pause while vfp has to find the correct one. Subsequent LOCATE or CONTINUE are about as fast as SEEK after that...same thing, of course, with SQL...

But that alone can be a reason to use SEEK instead of LOCATE (and even SQL where applicable), since order is already applied.