>>There was some talk on another VFP forum about including the capability of using files larger than 2gb in VFP7+. Call it a ."dbv" file format with an all-new header compared to the .dbf that can handle the largest "Oracle-class" tables. It would also do variable-length character columns...
>>
>>What do you think?
>
>I would rather just have a .dbf with all the capabilities of any major backend. <g>

Eric,

I see the < g > after your comment, but aside from the 2gig limit and the thorough logging of SQL Server it doesn't seem that unrealistic to me *IF* there's a will.
Adding NULLs support wasn't a trivial step by any means, yet they pilled it off! Adding improved security (possibly including encryption with the processing power now available), adding real deletion (or at least the option to IGNORE (tagged as) deleted records), allowing multiple-field (no operators) indexes, allowing variable length fields should all be far more easily doable than NULLs was. We sort of can do a "clustered index" today on our own, and maybe that's good enough for us.
There are no doubt lots of other things to consider, but these things would be a damned good start.

I initially thought, when I first read this idea, that it might be acceptable to have this "outside" of regular rushmore-capable VFP, but then I said to myself 'but then it wouldn't be *VFP* so I dropped that reply.

Cheers,

JimN