>3 bytes would probably be just fine for VFP as things now stand. The max. records is 1 billion but that means a 1 byte record (the other byte is the delete mark). I can't think of many uses for a 1 byte table - at least not with 1 billion entries! I would also guess that 16.7 million records would present other problems in day-to-day usage. I suspect that somewhere around 2 million records is a "practical" limit.
>
>The speculation about the bit-mapping doesn't seem to make allowances for B-Tree functionality. Surely that has to play some important role in all of this.

Set Speculate On Additive

I think the B-tree is used to create only the relevant sections of the bitmap - probably the bitmap gets created as a sufficient number of zeros, and gets expanded on either lower or upper end, as new records are encountered - and using the tags makes sure the minimal number of records (i.e. their tag entries) gets examined.

>Similarly, speculation about the bit-mapping implies (to me, as I have read this thread) that the whole index would necessarily be read into RAM. I have to wonder about this too.

I guess it finds the proper place in the index for the condition given (in Charlie's example, only the part of the Name tag where eval(key())="Charlie"), and loads only that part of the index. That's why the deleted() is not that nice - on a large table, it has to read the .t. or the .f. part of the index, which is probably almost all of it, while some tags with more values leave it far better off.

>Finally, and this may be what Dragan was saying, even if the whole index *is* read in, the order should be immaterial for bit-map *building* purposes, since the record number is supplied with each index entry (thus providing the offset for the bit in question anyway).

Sure, I think the ordering may come into play _after_ the bitmap is created. If the ordering is immaterial, the records are retrieved in their physical order; if it is, the bitmap has to be read in a certain order, which probably means lots of up'n'downs along the bitmap. In case of a For clause, it needs reading the next index value, it's corresponding recno(), looking up the bitmap to see if it's a 1 or 0, then taking that one or skipping to the next.

Set Speculate off, but I've been right couple of times before :)