| Previous | Next |
| hrInvalidBackup | hrMissingLogFile |
hrRecoveredWithErrors
Operational meaning
hrRecoveredWithErrors means repair or restore completed far enough to produce output but encountered errors that affect confidence in the result.
The stored value is 0xC800020F (negative JET error -527; -527). Current ESE documentation uses JET_errRecoveredWithErrors for the corresponding published JET condition.
The first useful distinction is that this is not clean success; using the database without validation can conceal lost or inconsistent data. Start by collecting every preceding repair event, affected page/table, skipped operation, final database state, and application-level verification results.
Before altering files or retrying
- Code-specific observation: collect every preceding repair event, affected page/table, skipped operation, final database state, and application-level verification results.
Comparison points
It specifically means that this is not clean success; using the database without validation can conceal lost or inconsistent data. 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 |
|---|---|
hrConsistentTimeMismatch | the database last-consistent timestamp does not match the recovery or backup lineage being applied |
hrDatabaseInconsistent | the database is not in a clean transaction-consistent state and requires recovery before normal use |
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 | repair or restore completed far enough to produce output but encountered errors that affect confidence in the result |
| Narrow corrective direction | preserve the original, validate the recovered copy, and prefer restoration from a known-good backup where available |
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.
Recommended handling
- Record it,
0xC800020F, the API name, the current phase, and all live context or file owners. - Verify the condition by collecting every preceding repair event, affected page/table, skipped operation, final database state, and application-level verification results.
- Apply only the targeted fix: preserve the original, validate the recovered copy, and prefer restoration from a known-good backup where available.
Acceptance criteria for a fix
A useful regression test should force the condition “repair or restore completed far enough to produce output but encountered errors that affect confidence in the result”, call one documented API transition, and assert the exact HRESULT.
Actions that can make diagnosis worse
- Do not attach a dirty or mismatched database as if it were clean.
- Do not modify the only backup copy in place.
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.