>It may be jumping to 4 bytes when it reaches that limit, or having a limitation to "only the records with the same MSB in one block", or whatever. The great thing with CDXes was their compactness, right? Did you ever take a look at the innards of a .cdx? Imagine you had three names, "Peter Pan", "Peter Panowsky", "Peter Paulsen" and "Peter Peterson". In the CDX, you could find "Peter Petersonaulsennowsky". Yes, it's going from last to first and shoot me if I know where it stores the offsets and lenghts. It's full of neat coding tricks.
>
Thanks for your insight. I saw the run-together info, but didn't understand what I was looking at. It may be VFP uses 2 bytes, then 3, then 4, as needed.

>Now it would really be nice to know some good benchmarking on this. My guess would be that it would retrieve the parts of the index for Name tag for "Charlie" only, and then pull the Sex index for those which are in the already selected part... but then this should mean that each tag is internally indexed by recno() as well... which is unlikely, IMO, so my bet is on your 2nd example. The third one is worse - it would run on the result set (as being unoptimizable) just like the second, but it requires a function call so it would be slower.
>
I made a little test data program on Saturday, generated .5 million records, and have been using them to test. From what I can tell the answer is the ever popular, "It depends." If there are lots of "Charlie"s in a table and the result set is large, doing all the work at the index level is a good thing, especially since VFP caches so well. But what about concurrency? If there is a lot of caching, it could be stale quickly. If the result set is small, the added index fetching slows things down.
>
>>The LOCATE with a FOR and SET ORDER TO Something is still wrong in that it shouldn't care about the active tag. It's as if the old code before Rushmore optimization didn't quite all get examined.
>
>It has to take care of the active tag, because that's the expected behavior: it should jump to the first located record - but first according to the active tag, so it actually has to build the complete bitmap and then arrange it to the active tag. That's why the Continue works like a snap after this, and only the first Locate takes a while.
>
I forgot about CONTINUE, and I see your point. I couldn't see the difference between GO RecNO(),SEEK, and LOCATE, but now I do. Thanks. Sorry MS, now I get it.
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.

>I'm wandering if Locate Rest or Locate While are retrieving records physically according to the active tag, or does it still build a bitmap, just made shorter by using the info from the current tag (current record's key and higher).
>
My quess it's the latter. Seems like indices are involved whenever possible.

>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.