>>> I've always had trouble with the idea that Rushmore works faster with *NO* order set. Since you seem to speak somewhat (at least) knowledgeably regarding this "map" concept, perhaps you could clarify this for me?
>
>I'm not sure how much the technology has changed and how much I remember correctly :), but basically Fox has 64K chunks of memory for creating bitmaps of records that match a given optimizable condition. The bitmap stores a 0 or 1 for each record, bit by bit, based on the physical record order. If the table is ordered, then VFP has to figure out where in the table a bit (that represents a record) is relative to the current index.

I actually remember having read that this applies to SQL Selects, and not just to anything with a FOR clause. Besides, when it does something FOR against a current index, it actually goes down the index, and matches the record number (stored along with the index) against the bitmap, and retrieves or skips the record. Or am I wrong?