Visual FoxPro: reading .dbf, .scx and .frx files after end of support

Visual FoxPro applications are frequently the best software in the building. They are fast, they were written by somebody who understood the business, and they have run for twenty years without much attention. That is precisely why nobody has dealt with them, and why the decision usually arrives as an emergency rather than a plan.

Where Visual FoxPro stands

Microsoft shipped Visual FoxPro 9 in 2004, announced in 2007 that there would be no version 10, and ended extended support on 13 January 2015. There is no successor product and no migration path provided by the vendor.

What did not happen is the applications stopping. A compiled VFP application keeps running on current Windows, which is why so many are still in production a decade after support ended. The pressure comes from somewhere else: the person who wrote it retires, a Windows update breaks a printing or ODBC dependency, or an auditor asks where the data lives and who can access it.

What each file extension holds

A useful detail: .scx, .frx, .vcx and .pjx are themselves .dbf files with different extensions. That means the forms, reports and class libraries can be opened and read as tables, which is how their contents are recovered when the development environment is not available.

Getting the data out

The .dbf format is documented and old enough to be very widely supported. You do not need Visual FoxPro installed to read it, which matters because installing VFP on a current machine is its own small ordeal.

The practical sequence:

1. Copy the whole data directory. Every .dbf with its matching .cdx and .fpt, plus the .dbc set. Work from the copy.
2. Read the database container. The .dbc holds relationships, field validation rules and stored procedures. It is the closest thing to a schema document you will get.
3. Extract each table into a staging database, mapping types conservatively so nothing is rounded or truncated on the way in.
4. Verify the memo fields arrived. Explicitly. Count non-empty memo values in the source and the destination and compare them.
5. Reconcile against a report the business already runs, before anything is relied upon.

Reading the forms and reports

The business rules in a VFP application are not in one place, which is the main reason rebuilds get underestimated. Expect to find logic in all of these:

• .prg files. Plain readable source, the easiest part.
• Form methods inside .scx. Validation and calculation attached to controls, in Valid, When and InteractiveChange events.
• The .dbc stored procedures. Field-level rules and referential integrity that fire regardless of which screen is used.
• Class libraries in .vcx. Behaviour inherited by many forms at once, so a rule can apply everywhere without appearing in any individual form.
• Report formulas in .frx. Calculations that exist only in the report, which is the same problem Crystal Reports has.

Because all four of those file types are readable as tables, the logic can be recovered systematically even without the development environment. It is methodical work rather than clever work.

The traps that corrupt a migration

• Memo fields left behind. Covered above and worth repeating, because it is the one that gets discovered months later.
• Deleted records are not deleted. VFP marks rows deleted rather than removing them, and they stay in the file until the table is packed. Extract everything and you resurrect records the business removed years ago.
• Empty dates. VFP has a genuine empty date value that is not null and not a zero date. Mapped carelessly it becomes 1899 or 1900 and pollutes every date comparison downstream.
• Trailing spaces. Character fields are fixed width and space padded. Import without trimming and joins that should match silently fail.
• Code pages. Data written under DOS or older Windows uses a code page, not Unicode. Accented characters are the casualty.
• Currency and numeric precision. VFP has a distinct Currency type with fixed decimal places. Map it to a float and you introduce rounding differences that show up in totals.

The staged approach that usually works best

Full rebuilds fail more often than staged ones, and Visual FoxPro happens to support a genuinely low-risk sequence:

1. Move the data to SQL Server, keep the FoxPro front end. VFP can work against SQL Server through remote views or ODBC, so the screens your staff know keep working while the data gains real backups, real permissions and reportability.
2. Rebuild reporting first. Now that the data is in SQL Server, reporting can be rebuilt with ordinary tools and reconciled while the old reports still exist to compare against.
3. Replace the screens in groups. One module at a time against the same database, with both systems live.
4. Retire the FoxPro application when the last screen has moved, not before.

Each step delivers something on its own. If the project stops after step one, you have still removed the largest risks, which is the mark of a sensible sequence rather than a hopeful one.

The honest summary: Visual FoxPro skills are getting rarer every year, and that is a real constraint on finding help. The data and the logic are not the constraint. Both are recoverable with documented formats and patience.