Start by identifying the complete file set

A DBF file is a table: its header describes the columns and each following block stores one fixed-length record. It may not contain all of the information shown by the original application. Visual FoxPro often keeps long text, notes and binary values in a companion .fpt file. Older dBASE applications commonly use .dbt. Indexes can appear as .cdx, .idx or .ntx.

Before opening anything, copy every file with the same base name into a working folder. For CUSTOMER.DBF, preserve files such as CUSTOMER.FPT and CUSTOMER.CDX too. A viewer can usually display records without an index, but it cannot reconstruct memo text that exists only in a missing memo file.

Useful clues before you begin

  • The first byte of the DBF header identifies a format family. Values such as 0x03 are associated with dBASE III without memos, while FoxPro and Visual FoxPro use other signatures.
  • The field descriptors reveal names, types, lengths and decimal counts. Types such as character, numeric, date and logical are widely supported; newer FoxPro types need dialect-aware parsing.
  • A language-driver byte may suggest the original code page. It is a clue, not proof, because many applications wrote an incorrect or empty value.

A safe browser workflow

  1. Create a read-only archive. Keep an untouched copy of the source folder and record its origin and date.
  2. Open the working DBF. Launch DBF Viewer Pro and select the DBF plus its FPT or DBT companion when one exists. Parsing takes place locally in the browser.
  3. Inspect the schema first. Check whether column names and types make sense before interpreting record values.
  4. Review representative rows. Examine early, middle and late records, including accents, dates, decimals, deleted flags and memo columns.
  5. Export only after validation. CSV is convenient, but it loses native field types and memo relationships. Treat it as a derived file, not a replacement archive.

You do not need the Visual FoxPro runtime for this read-only inspection. You also avoid installing an abandoned development environment merely to understand a table. If the content is confidential, local browser processing removes the need to send the records to a conversion service.

How to tell whether the table opened correctly

A plausible grid is not sufficient evidence. Compare the displayed record count with any report produced by the old system. Check that dates remain valid calendar dates, numeric columns retain their sign and decimal scale, and identifier fields still contain leading zeros. Search for a known customer, product or transaction rather than trusting the first row alone.

If accented characters look like José or box-drawing symbols, the structure may be correct while the character encoding is wrong. Follow the DBF encoding guide before exporting. If memo columns are blank, use the FoxPro memo recovery checklist.

What a viewer can and cannot establish

A standalone table does not preserve every rule of the original application. Validation logic, calculated screens, relations between tables and business meanings may live in program code or in a Visual FoxPro database container. A viewer can expose the physical records and field definitions; it cannot infer undocumented business rules reliably.

For long-term use, inventory all related tables and document their keys before migration. The DBF migration plan explains how to reconcile row counts, types and relationships without treating a one-click export as a complete migration.