| Previous | Next |
| hrCheckpointCorrupt | hrConsistentTimeMismatch |
hrDatabaseInconsistent
What this return value changes
hrDatabaseInconsistent means the database is not in a clean transaction-consistent state and requires recovery before normal use.
The stored value is 0xC8000226 (negative JET error -550; -550). Current ESE documentation uses JET_errDatabaseInconsistent / JET_errDatabaseDirtyShutdown for the corresponding published JET condition.
The first useful distinction is that the legacy name is associated with dirty-shutdown semantics, not necessarily irreversible physical damage. Start by inspecting database state, consistent log position/time, required generation range, last shutdown, and available logs.
Objects and state involved
| Diagnostic layer | database, patch, log, and backup metadata that establish one recoverable lineage |
|---|---|
| Relevant API surface | hard recovery, database-header inspection, patch application, and post-restore validation |
| Code-specific condition | the database is not in a clean transaction-consistent state and requires recovery before normal use |
| Narrow corrective direction | run supported recovery with the matching log set or restore a verified backup; do not attach the file as clean |
A hard-recovery failure leaves the restored database invalid; retry begins from a fresh restored copy. Database state, signature, page size, consistent time, and required logs must agree.
Evidence worth preserving
- Code-specific observation: inspect database state, consistent log position/time, required generation range, last shutdown, and available logs.
How to distinguish nearby results
It specifically means that the legacy name is associated with dirty-shutdown semantics, not necessarily irreversible physical damage. Related values below can appear in the same workflow but require a different response:
hrBadBackupDatabaseSize | the backed-up database file length is not aligned to the database page-size boundary expected by ESE |
|---|---|
hrRecoveredWithErrors | repair or restore completed far enough to produce output but encountered errors that affect confidence in the result |
hrConsistentTimeMismatch | the database last-consistent timestamp does not match the recovery or backup lineage being applied |
A safe response sequence
- Record it,
0xC8000226, the API name, the current phase, and all live context or file owners. - Verify the condition by inspecting database state, consistent log position/time, required generation range, last shutdown, and available logs.
- Apply only the targeted fix: run supported recovery with the matching log set or restore a verified backup; do not attach the file as clean.
Actions that can make diagnosis worse
- Do not modify the only backup copy in place.
- Do not attach a dirty or mismatched database as if it were clean.
Acceptance criteria for a fix
A useful regression test should force the condition “the database is not in a clean transaction-consistent state and requires recovery before normal use”, call one documented API transition, and assert the exact HRESULT.
Technical references
- JetExternalRestore behavior — API ordering, file semantics, warning/error interpretation, or recovery behavior relevant to this HRESULT.
- Database header information
- ESE error-code table
- Microsoft JET_ERR enumeration
Looking for a different code? Search another status or error code.