First off, I am not sure why we are even discussing Locate. Unless we are talking about a non-indexed field, it has NO value. Best to use Seek.

Now, if we are talking about looping though a set of records ALA Scan/EndScan, the fasted combination is a Seek and then a Scan While. Many folks do a Scan For... This causes ALL records in the table to be evaluated. At the very least, the whole index has to be checked. Now, with Rushmore, this can still be very fast, however, it can get faster.

By seeking a specfic record, and then scanning WHILE a condition is true, allows you to bail out of the operation when an irrelevant record is encountered?

The speed improvements? I have seen speed improvements of 10X or more...

So you see, the seek is a bit of a red herring here.. The real speed is in using the WHILE clause. Not the FOR clause. I bet 80% of the time a FOR clause is used, A WHILE clause with a SEEK could be used instead, dramatically improving performance...

If there is one thing I pulled out of my time at MEI and working with George Goley, it was in how Rushmore works, and how to quickly process data.....

So your query below about me proving SEEK is faster than LOCATE is really not that accurate. In fact, I was not trying to say that. The issue is that a combination of SEEK and SCAN WHILE is faster than SCAN FOR in large table operations. If it is one row you need to find, chances are, if you are doing a locate for x = y, the field should be indexed.

What would you rather do?

IF Seek()


Or

Locate For
If Found()


OK????


>I am confused here John... and if you have some inside info please share it... but, if there is an index on STATE what does the foxpro engine do different for...
>
>SEEK('PA')
>
>or
>
>LOCATE for STATE='PA'
>
>Seems to me it (the VFP Engine) still has to read the index to determine where the first value of PA is. The only small overhead I see with LOCATE is it has to decide which index to use as opposed to being told.
>
>Unless you are saying that SEEK DOES Sometype of hashing or some type of index magic that LOCATE doesn't do.
>
>I would even guess (no treu knowledge here) that there is a function like FindValueInIndex() that both locate and seek use. Locate just does a bit of stuff first to see which index to use, which takes how long?
>

>Have you benchmarked the speed of Seek Vs Locate? Thanks for providing technical specifics that prove seek is 'MUCH Faster' than Locate.
>
>BOb