A DBF file is a table artifact used by several families of applications and data tools. Its records acquire meaning through a particular format variant, associated files, and application rules. Reading rows successfully establishes only that a reader interpreted some part of that artifact.
The historical Microsoft FoxPro formats illustrate the distinction. Their table structures include version markers, record deletion flags, and a code-page marker. Memo content can reside in a separate FPT file referenced from the table. These properties are specific evidence about those documented formats, not a universal specification for every DBF.
Identify the variant before choosing a reader
The filename extension does not distinguish all table layouts. A reader needs to support the actual header and field definitions, including the conventions used by the creating application.
FoxPro 2.x and Visual FoxPro markers differ in the archived table specification. A tool advertised as a DBF importer therefore needs a more precise compatibility claim before its output can serve as migration evidence.
The executable deserves separate identification. An older file format does not establish whether its application needs a particular operating system, runtime, or processor architecture. File compatibility and execution compatibility are different investigations.
Preserve the complete artifact set
In the documented FoxPro memo layout, the table stores block references and the FPT file holds memo data. Copying the table without its associated content can preserve a field reference while losing the information it identifies.
An inventory should associate tables with memo files, indexes, application files, and known external consumers. Copying should begin from a recoverable reference state whose consistency is understood. The format description alone does not establish a safe concurrent-copy procedure.
Indexes also need an explicit treatment. A decision to preserve or rebuild them depends on their role and the target environment. An importer’s default should not silently become the migration policy.
Physical presence and business visibility differ
A deletion flag allows a record to remain physically present while being treated differently by application logic. A physical record count can therefore differ from the dataset a user sees during a business operation.
Suppose a table contains records that the original application excludes from an outstanding-orders screen. An import that includes all physical records could reproduce the file count while changing the outstanding total. An import that excludes them could lose information needed for historical investigation.
The acceptance rule needs to name both the population being compared and the treatment of excluded records. Neither including everything nor dropping every flagged record is a universal answer.
Conversion requires semantic decisions
Text decoding must preserve meaning, including non-ASCII characters. Numeric conversion must preserve the precision required by the business. Dates, empty values, nulls, and long memo fields need representative comparisons against the reference application.
A target relational schema can make previously implicit rules explicit. It can also introduce constraints that reject source records. Rejected rows need traceable reasons and an agreed correction process; silently coercing values conceals the difference between conversion and repair.
Record-level comparison should accompany business reconciliation. Correctly reading several sample rows does not establish that all customer balances, open cases, or historical notes were preserved.
Include consumers outside the application
A report, spreadsheet, or overnight utility can depend directly on a DBF filename or field layout. Replacing the main application does not automatically replace these readers and writers.
Migration acceptance should account for those consumers, reconcile the defined business dataset, and retain the original artifacts until the result is accepted. Historical format documentation helps explain the bytes. Local evidence must establish locking behavior, runtime compatibility, and the operational consequences of changing them.