Craig Berntson repeats the same old myths about the Visual FoxPro 2 gigabyte limit: The 2 Gig File Limit
What nonsense! I am sure that changing the logic of record locking to support more than 2 Gb of file space is a non-trivial change. I have no doubt that there are a lot of places in VFP where the 2 Gb limit is hard-coded or, worse, assumed. But to claim it is primarily for backwards compatibility is nonsense. Nearly every format in VFP changes regularly. Menus added shortcut icons, breaking backwards compatibility. Auto-incrementing fields, code pages, and DBC backlinks all changed the DBF format, breaking backwards compatibility. Database events… guess what? … broke backwards compatibility.
There are two reasons, besides for the hard work involved, for not increasing the DBF beyond 2 Gb. One I agree with, and one I detest. The good reason is that DBFs, ISAM files, are unstable, and rebuilding ever bigger ones is expensive. Ever reindex a 2 Gb DBF? It can take forever. So, bigger is not better for ISAM. Moving to client-server when you have that much data is a good idea, solely for data recovery time.
The second reason is the dumb one. Microsoft doesn’t want to raise the limit because it will eat away at its other product offerings. MSDE and now SQL Server Select are the low-cost entries into client-server computing, and their reason for being would be hurt by letting DBFs grow to a larger size.
A Spoke in the Wheel
Steve Sawyer, the man when it comes to VFP RI, and an insightful developer, is off on his next career, but we can still catch a little wisdom from his blog, such as A Spoke in the Wheel: “The most carefully formulated business processes can be short-circuited, sidetracked, derailed or otherwise thwarted by the very people responsible for implementing or following the process.” Source: Steve’s Transitions Journal