Deleting a DBF record often starts with a flag
In traditional DBF layouts, each record begins with a status byte. An active record and a record marked for deletion can still occupy the same amount of space and retain the same field bytes. Applications commonly hide marked rows, which makes them appear gone even though their content remains physically present.
This two-stage model supported fast deletion on older hardware. It also creates an important forensic distinction: “marked as deleted” is not the same as “physically removed.”
When a marked record can still be read
If the record slot and its field bytes remain intact, a read-only parser can expose the deletion state and the stored values. Memo content is less predictable: the DBF pointer may survive, but the corresponding memo block may have been reused or damaged. Indexes may exclude marked records even while physical inspection finds them.
Recoverability decreases after the source application continues writing, rebuilds files or performs a packing operation. Filesystem recovery may be required when physical bytes have already been removed, so preserve the complete storage device when the records are legally or operationally important.
RECALL changes flags; PACK rewrites the table
| Operation | General effect | Risk |
|---|---|---|
| DELETE or equivalent | Marks selected records as deleted | Rows disappear from normal application views and indexes. |
| RECALL | Clears deletion marks for selected records | Can restore unwanted or obsolete rows and violate application rules. |
| PACK | Rewrites the table without marked records | Physical row positions change; deleted data is removed from the new table. |
| Index rebuild | Regenerates keys from current records | May alter visible order or expose uniqueness conflicts. |
Exact behavior depends on the xBase product and configuration. Never issue these commands against the only copy merely to see what happens.
A safe recovery and migration workflow
- Freeze and checksum the original DBF, memo companions and index files.
- Use a working copy and inspect deletion flags without modifying records.
- Export active and marked records separately, retaining a stable source identifier and deletion status.
- Ask the data owner whether deleted rows represent mistakes, cancellations, historical states or legal erasure requests.
- Restore only into a new recovery database and validate relationships before use.
DBF Viewer Pro is appropriate for local inspection and export, but it deliberately does not present PACK as a casual repair feature. When header values or record boundaries are inconsistent, first follow the corrupted DBF header procedure.