Specialist · database engines
SQL Server and Exchange keep strict internal accounts, and both would sooner refuse a database than guess at one. Their built-in repair options reach consistency by discarding whatever fails the audit. So the order of work here never changes: every MDF, LDF and EDB that reaches us from Exeter is imaged before any tool runs, and repair lands on the copies — the files you send are read once, then set aside.
Talk it over with an engineer
0800 6890668
| What's wrong | What it usually means | Step one |
|---|---|---|
| Database shown as Suspect in SQL Server | Replay of the transaction log failed after an unclean stop | Copy off the MDF and LDF right away |
| Recovery Pending and no progress | The start-up pass has stuck — commonly a failing disk below | Get the storage seen to as well |
| Torn pages, or errors 823 and 824 | The engine hit damaged pages mid-read | No more retries — image the files |
| The 5171 error — ‘not a primary database file’ | The header of the MDF is broken | Header repair, done on a copy |
| An EDB stuck in Dirty Shutdown | Outstanding logs never reached the database | Begin with a harmless header check |
| Somebody already ran a hard repair | The name REPAIR_ALLOW_DATA_LOSS is honest about what it costs | Send it in regardless |
Your device is logged under its own case number the day it arrives. An engineer finds the fault, tells you plainly what stands a real chance of coming back, and writes you one fixed quote. Nothing is charged for that look, nothing obliges you, and paid work starts only when you say so.
Data files, logs and backups are imaged without a single write; failing storage goes through our server and RAID workflow first, so what we repair is a sound copy.
All on the copies: headers put back together, logs replayed where they are sound — and where they are not, purpose-built tools read the file’s internal pages directly and bring out tables, mailboxes and attachments.
The finish line is the engine’s own acceptance: the database attaches or the store mounts, queries come back, and the items you flagged as critical are checked by hand. Sign-off comes after that, not before.
Before any fee falls due you see a full listing of everything recovered and approve it. Your files travel back on brand-new media, return postage on us, and the case stays open until you've confirmed everything opens on your own machine.
Where the bar actually sits: a file-recovery job ends when the bytes exist again. A database job ends when the engine attaches the file, mounts it and answers queries without complaint. Consistency is the distance between those two finishes — and it is why MDFs ‘recovered’ elsewhere keep arriving here, still refusing to attach.
Power failed in the night and the database woke in Suspect. An IT contractor stood ready with the emergency repair, but forensic copies showed the log would still replay. Working on the copy, we attached it first time, and that morning's bookings slipped by twenty minutes, not by a week.
Do the simple thing: take it offline and get copies of the MDF and LDF stored safely before you run a single command. Suspect just says the engine couldn't replay its log cleanly after an untidy shutdown — usually very recoverable. What loses it permanently is a well-intended repair run against the original files.
The data file alone will normally do it: it holds nearly everything and can usually be persuaded into an attachable state without its log. The trade-off: whatever was mid-transaction at the moment of failure may come back incomplete. We'll show you exactly where that boundary sat on your system.
Not usually. Dirty Shutdown just says the database still has log files waiting to go in. A read-only header check will list them, then soft recovery replays the ones that remain. Nearly always the mail itself is fine — the real risk is reaching for the hard-repair shortcut.
Because the real patient isn't the database — it's the storage underneath. When corruption keeps coming back, the cause is almost always a failing disk, a degraded array or a faulty cache pressing fresh damage into every 'repaired' copy. What looks like a database problem is a server recovery in disguise, and we handle the pair.
Each power-up of a failing device takes more data with it. Open a case first — the look-over is free whichever way it goes.