Hi Samuel,

>Yes you are right. The Memo info has to be extended to 8 bytes instead of just 4 bytes, this is the part that goes into the dbf.
Here my personal favorite would be the creation of a new field type "Huge Memo" or something alike, since I guess most tables wont need these large memo fields. Even when table and record size borders are not problematic, unnecessary spent space often translates into uneccessary speed loss: those added 4 bytes have to be worked on.

>Also the CDX should have a little tweak to make room for record numbers of 8 bytes (64 bits).
And this also should be needed on tables marked as "HugeReccount". Here the bottleneck is found when Rushmore sucks a large part of a key with low selectivity through the network.

>Because the VFP dbf header has some unused fields, it could be easily extended to make room for more than 4 billion records, that is the path we are taking for this. The Max record size (64k) is redundant with the 0XD marker for the end of fields, so this could be ignored.

I hope you are not using a totally new configuration but are re-implementing one vfp file format already enhanced like codebase or others: the "esperanto" character of dbf's should be kept alive, and even if there are only few users of the format further fragmentation should be avoided unless very sound/pressing technical reasons exist. But I am probably only second guessing something you already decided on...

regards

thomas