Preserve the DOS-era application folder

Clipper applications commonly used DBF tables but could combine them with memo and index formats selected by the developer or a third-party replaceable database driver. The extension alone does not reveal the complete storage design. Copy the whole data directory, including files with .dbt, .fpt, .ntx, .idx and unusual extensions documented by the application.

Do not run the original program against the only copy. An old executable may rebuild indexes, update a last-opened value or expect DOS locking behavior. Begin with a read-only archive and a separate inspection copy.

Identify what the DBF actually contains

Classic Clipper tables often resemble dBASE III structures, but production systems vary. Inspect the version byte, header and field descriptors. Verify that declared header length, record length and record count are plausible for the physical file size. Field names may be abbreviated to fit historical limits, so preserve them exactly before assigning modern labels.

  • Character fields may contain CP437, CP850 or another OEM code page.
  • Logical values can use several byte representations, including blank or unknown states.
  • Date values usually appear as eight characters in YYYYMMDD form, with blanks possible.
  • Numeric values are stored as text in many traditional DBF dialects and may contain blanks or overflow marks.

Indexes are useful context, not the source table

An NTX or other index stores ordering expressions and keys; the underlying records remain in the DBF. A general viewer can normally inspect physical DBF order without the index. What may be missing is the business order used by the application or the expression that linked records.

Memo fields are different: their payload is outside the DBF. Pair DBT or FPT files from the same backup generation. If notes are blank, consult DBF, FPT and DBT files explained before assuming data loss.

Create an evidence-based extraction

  1. Open a working copy locally and record the displayed schema and row count.
  2. Check known records from different periods, including accented text, deleted rows and memo values.
  3. Determine whether deleted records should be excluded, retained for audit, or handled separately.
  4. Export a UTF-8 CSV and reconcile its rows, identifiers and totals.
  5. Document inferred relationships between tables before importing them into a new database.

When several tables form one application, filenames and shared values can suggest keys, but only source code, reports or domain experts can confirm business meaning. The controlled migration plan explains how to turn this inventory into SQLite or MySQL without losing the audit trail.