Treat corruption as a diagnosis, not a button
The DBF header contains a version signature, last-update bytes, record count, header length and record length, followed by field descriptors and a terminator. Damage to one value can make a healthy record area appear unreadable. Conversely, a plausible header cannot restore bytes that were physically truncated.
Common warning signs include an impossible record count, a header length that ends inside the field-descriptor list, a zero record length despite defined fields, field widths that do not add up, or a file whose physical size is shorter than its own declarations.
Use the file size as an independent check
For a simple DBF, the expected minimum size is approximately:
header_length + (record_count × record_length) + end_markerSome variants and damaged files do not follow the final-byte convention exactly, but a large mismatch is meaningful. If the file has enough bytes for 10,000 records while the header claims 900 million, the count is suspect. If the declared rows require more bytes than exist, the file may be truncated or its count may not have been finalized after a crash.
Also calculate record length from the field descriptors: one deletion-status byte plus the sum of field widths for traditional layouts. Newer FoxPro features can add nuance, so apply dialect-specific rules before rewriting anything.
A non-destructive recovery workflow
- Freeze the source. Copy the DBF and companion files, record sizes and calculate checksums.
- Collect comparison files. An earlier backup or another table created by the same application can reveal the expected dialect and header conventions.
- Parse as far as the evidence allows. Test the declared header, then compare calculated record boundaries with repeated data patterns.
- Recover into a new file. Never patch the source. Write extracted records or a reconstructed DBF to a clearly named recovery directory.
- Validate business values. Compare identifiers, row counts, totals, date ranges and a sample of deleted records.
| Symptom | Possible cause | Evidence to seek |
|---|---|---|
| Viewer stops before any row | Invalid header or unsupported dialect | Version byte, header terminator, field descriptor boundaries. |
| First rows work, later rows shift | Wrong record length or mid-file damage | Repeated deletion flag and field boundary patterns. |
| Rows work, memos fail | Separate FPT/DBT problem | Memo pointers, block size and companion file length. |
| Recent rows are absent | Truncation or older backup | Physical size, timestamps and newer copies. |
Know when specialist recovery is justified
DBF Viewer Pro is intended for inspection and export; it does not promise automatic forensic repair. When payroll, legal, clinical or irreplaceable records are involved, preserve disk images and use a specialist who can document every transformation. A guessed header can produce convincing but misaligned data.
If the affected table uses memo fields, diagnose the companion independently with the FoxPro memo recovery guide. For preventive controls, follow the sensitive DBF backup procedure.