Getting your data out of FoxPro, dBase and DBF files

FoxPro, dBase and Clipper systems all store their data in DBF files, a format that has been around since the early 1980s. The good news is that DBF is well documented and your data is almost certainly recoverable, even if the program that created it no longer runs.

The bad news is that a quick export often produces subtly wrong results that only come to light months later.

The files you’ll find

Each table is a .dbf file, but it rarely travels alone:

• Memo files hold longer text such as notes and descriptions: .fpt for FoxPro, .dbt for dBase and Clipper. Lose these and you lose every notes field in the system.
• Index files speed up searching: .cdx or .idx for FoxPro, .ndx or .mdx for dBase, .ntx for Clipper. They can be rebuilt, but they tell you how the system expects data to be ordered.
• Database containers (.dbc) in Visual FoxPro hold relationships, long field names and validation rules.

The traps

Character sets. Older systems stored text using DOS code pages, so pound signs, accents and special characters come out garbled unless the conversion is set correctly. In a UK business system that usually means every price description with a £ in it.

Deleted records. DBF files don’t remove deleted rows straight away; they flag them as deleted. A naive export can bring years of deleted customers and invoices back to life.

Dates and blanks. Empty dates, zero values and blank fields are stored differently from modern databases and need deliberate handling, or your reports will be full of 1899 dates and phantom zeros.

Drivers. The Microsoft ODBC driver for FoxPro only understands older table formats, and the OLE DB provider is 32-bit only. The standard tools often fail on newer Visual FoxPro tables or inside 64-bit software, which is why so many exports end halfway.

Doing it properly

A clean extraction works from a copy of the files, never the live system. It brings across every table with its memo fields intact, converts character sets correctly, flags or removes deleted records deliberately, and checks record counts before and after so you know nothing has gone missing.

The output can be whatever you need next: Excel or CSV for reference, SQL Server or PostgreSQL for reporting, or a direct import into a new system such as Odoo.

It’s also the right first step if you need to keep old records for compliance, such as the six years of financial records HMRC expects, but want to retire the old system. We offer this as a fixed-price data rescue. Tell us what you’ve got and we’ll quote.