This project is read-only.

Foxpro File Limits

Topics: General
Jun 6, 2015 at 2:54 AM
I have used Foxpro for 20 years. Its at the point that my databases are exceeding the file size limits. Is there a fix for this? If not any suggestions for easy migration to a new system? Right now I am using VFP 9.0
Jun 6, 2015 at 9:44 AM

It's really not so complicated. If you are reaching the 2 GB limit you have 2 or more chices:

1) You can decompose you table in little tables if there is room for it.

2) You can migrate your data to another database (MySql, MariaDB, SQLServer, Firebird, etc) and keep using your programs in VFP, but this would need some reprogramming, depending on if you have used N-Tier programming or not.

Best Regards!
Jun 6, 2015 at 10:11 AM
I'm not sure, what this question has to do with CodePlex or VFPX; it would be asked better on any of the usual VFP support forums (like Foxite, Universal Thread etc)

In short: No, there's no direct fix to extend the VFP file limits. You could switch your data-storage to any of the SQL based Backends and address that through ODBC. Depending on your coding style, this could be a nobrainer (if you used a clean encapsulated data-access strategy) or a major rewrite. Take a look at ADS ("Advantage Database Server") from Sybase (now part of SAP) , which uses VFP tables in a "Compatibility Mode", thus you can use those tables directly and also from ADS; and later on (when you are finished with porting), switch to native mode, which then alters the VFP tables to get rid of the size limits and grow into terabyte sizes. (And yes: the xBase filestructure is extremely fast and stable and scales up to TeraBytes; it is just the old backward compatibility problem and the "we don't want to hurt SQLServer", that MS didn't changed that)

Thus you need to look at your data, and why it reaches the limit. You have three choices:
a) Just delete older data, it just slows down your system, and no one looks at it anyway.
b) Or you could export older data to some sort of an archive datafolder, and just extend your system with some datechecking and switch to the archive database if needed.
c) If you need all records, but the records itself are very big, then you can part those into two (or more) parallel tables and just use them together. This is even supported natively by xBase, since you can relate those siblings directly by Recordnumber, without using any additional index and Primaryfield in those parallel tables..

Migration? There is no easy migration, since modern systems incorporate modern requirements like Mobile and Web usage and therefore require changes in usage-patterns, program-flow and design. There are some systems which can reuse your VFP sourcecode like PolarFox from Alaska, or Lianja (which I would recommend), and others which require a complete rewrite like AlphaFour, Basis or Servoy. But a rewrite has also benefits, since it forces you to rethink your application...