Data Recovery Case File · Formatted & Logical Faults · The Prompt Is a Decision
An Application Repairing Its Own Database Rewrites the Thing You Want Preserved
Her enquiry catches a decision at the moment it is offered. Payroll software that reported "this data file is corrupt — do you want the program to automatically attempt data recovery?", with a second error naming a prior year's file when she agreed. The prompt is doing something reasonable and it is not free: an automatic repair rewrites the file, and on business records that decision deserves more than a click.
| Media | Business accounting data files on working storage — application reporting file corruption and offering an automatic repair; a second file reported corrupt on attempting it |
| Reported situation | Payroll processing attempted as usual · application reporting the current data file as corrupt · automatic repair offered by the application · repair attempted · a second error reported naming a prior year file as corrupt · help function not responding · business records required |
| Fault class | Application database corruption with a built-in repair offered — repair rewriting the file in place; multiple files affected suggesting a common cause below the application |
| Equipment used | Copies of all data files taken before any further repair was attempted · repair offer identified as a rewrite rather than a read · underlying storage assessed for faults affecting multiple files · database structures examined and rebuilt from copies rather than in place · records validated against expected reporting totals |
The decode: what the repair does, and why two files matters
What the application stores: a database rather than documents. Every record lives inside one structured file with its own internal indexes and consistency rules, which is why a single fault can make the whole year unusable.
What its repair function does: reads what it can, discards what it cannot reconcile, and writes a corrected file. It is a rewrite rather than a read — and records it cannot make sense of are dropped rather than flagged.
Why that is usually acceptable and here is not: for an application recovering its own working file, dropping unreadable records is the right trade. For payroll records that may need to be produced years later, silently discarding entries is a different proposition.
What should have happened first, and can still happen now: a copy of every data file taken before anything else. A repair run against a copy costs nothing if it fails, and the original remains available for a different approach.
Why the second error is the most important detail in her account: a different file, from a different year, also reported corrupt. Two independent files failing together points below the application — at the storage holding both, rather than at either file.
Why that changes the priority entirely: if the drive is developing faults, every further operation is being performed on a degrading device. An application repeatedly rewriting large files on failing storage is the worst combination available.
What should therefore be established before any more repairs: the health of the drive itself. That is a quick check and it decides whether this is a software problem or a hardware one wearing software clothing.
Why the help function not responding is worth noticing: another component of the same installation failing. It suggests something broader than one corrupt file — either a damaged installation or, again, the storage beneath it.
What recovery of a database actually involves: examining the file's internal structures and rebuilding the parts that describe where records sit. Records intact but unreferenced are recoverable, which is precisely what an automatic repair would have discarded.
What must not happen now: no further repair attempts, no processing run against the files, and nothing written to that storage. Copies first, assessment second, repair last.
On the bench
Copies of all data files were taken before any further repair was attempted — the application storing records in a structured database file with internal indexes, and its repair function reading what it can, discarding what it cannot reconcile, and writing a corrected file, so records that cannot be interpreted are dropped rather than flagged. Underlying storage was assessed for faults affecting multiple files, two independent files failing together indicating a cause below the application.
The outcome
Copies taken before any further repair, the underlying storage assessed, and database structures rebuilt from copies rather than in place. Free assessment, one fixed written figure including VAT. The decode: the repair offer is a rewrite rather than a read, and it drops records it cannot reconcile. The detail that matters most is the second file — two independent files failing together points at the storage beneath them rather than at either file.
When an application offers to repair its own data file
Copy every data file elsewhere before accepting, since the repair is a rewrite rather than a read — it reads what it can, discards what it cannot reconcile, and writes a corrected file, dropping records rather than flagging them. That trade is reasonable for a working file and questionable for records you may need to produce years later. If a second, unrelated file also reports corrupt, treat that as the important signal: two independent files failing together points below the application at the storage holding both. Check the drive before running any further repairs.
Copy the files before accepting — call Manchester Data Recovery on 0161 871 0788; repair identified as a rewrite rather than a read, underlying storage assessed, structures rebuilt from copies rather than in place.
Request a quote online →
Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.