>I tested with two instances of VFP. I opened a table in both apps. SET ORDER TO Name on both. LOCATE FOR UPPER(Name) = "DD". Assume a find on the name Ddaa. Assume the next record is Ddbb, and the next Ddcc. Go to the other instance of the table and change some name to Ddbz. Go back to the original instance and CONTINUE. I expected the result to be Ddbb, then Ddbz, but no, Ddbz was not found with a CONTINUE. However, LOCATE does find a newly changed record, so there the index is re-read. Unless I've erred, CONTINUE won't find records that have been updated or added since the original LOCATE was called. I guess I don't mind, I just didn't know it worked like that.

That was a really good test. So it seems LOCATE builds the bitmap, and CONTINUE just uses it - not updating on the way. Why not, it's just good to know it. If we needed the ever-updating version, we can always LOCATE REST FOR < the same condition again > and it will rebuild the bitmap, running a good chance that only one page of the index in the cache is dirty, and it may actually still be fast enough.

>>Boy, I think they had lots of fun nine or ten years ago while they created Rushmore...

>Yep. By studying the amount of network traffic you can deduce some things, but the more you think you know, the more questions are raised.

And you actually get to admire the guys who made it. After - how many was it, actually? - some 8 years with Rushmore, I still haven't got into all of its tricks. I hope this doesn't create yet another club, like "Seekers for the Holy Grail of Rushmore Secrets" or anything of the kind.