Why Microsoft doen’t want Visual FoxPro to succeed

“For as far back as I can remember, FoxPro has had a 2 Gig limit on the size of a file. Before going any further, I’ll answer the big uestion…No, Visual FoxPro 9.0 does not support tables over 2 Gig in size. And don’t look for VFP to ever break that limit. Here’s why….”

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.