Corrupted file? We'll get your data back on track.

Corruption announces itself in a handful of recognizable ways. The file refuses to open with "Unrecognized database format". Rows in a table display as #Deleted. Access warns that the database "is in an inconsistent state", or a table called MSysCompactError appears after a failed compact. Sometimes it's subtler: a form freezes on one specific record, or the file has grown far beyond what its data justifies. Each symptom narrows down where the damage sits, in the file header, in a table's data pages, or in the VBA project, and that location determines the repair route.

The first move never varies: copy the file, set the original aside. Then the copy gets tested in a specific order. Will it open exclusively? Does Compact & Repair complete, and if not, what lands in MSysCompactError? Can objects be imported into a clean new database? Importing is the workhorse of Access repair. I bring objects across table by table, form by form, until the one that kills the import identifies itself. That's the damaged object; everything else is already safe inside the new file by the time it does.

The damaged object then gets handled on its own terms. A corrupt table can often be partially read with a query that steps around the poisoned rows, recovering everything on either side of them. A corrupt form or report gets rebuilt, usually quickly, from your last good backup or from scratch against the recovered tables. Only when all of that falls short do third-party recovery tools come in, and they run against yet another copy, never the original.

Before anything is handed back, the repaired database gets compared against expectations: row counts per table, known records checked field by field, every form opened, every report run. "It opens now" is not the test. The test is that the numbers your business relies on come out right.

Corruption also has causes worth naming, because a repaired file with the same cause in place will corrupt again. The usual suspects: several users opening one un-split database over the network, a machine that crashes or loses Wi-Fi while a write is in progress, the file living on a flaky share or a sync folder, and Access sessions killed through Task Manager instead of closed. Part of every repair I do is identifying which of these applied, and telling you what to change, because I'd rather not see the same file twice.