| Previous | Next |
| hrTooManyOpenDatabases | hrNotInitialized |
hrInvalidDatabase
Interpretation in ESE terms
hrInvalidDatabase means the selected file is not a usable ESE database for this operation.
This result is the legacy Directory Service backup/restore HRESULT form of the ESE condition normally written as JET_errInvalidDatabase. Preserve the original value 0xC8000404 when a wrapper also exposes a signed JET_ERR.
The key comparison is: hrDatabaseCorrupted indicates damage or an unavailable database; this result can simply be the wrong file type. The first useful observation is to inspect the file type, header, page size, provenance, and whether a log, checkpoint, or unrelated file was supplied. This evidence separates file identity, attachment, open-handle ownership, lock state, and structural validity.
The ESE objects in play
| Diagnostic layer | database file, attachment state, JET_DBID ownership, and database lifecycle |
|---|---|
| Typical API surface | JetCreateDatabase, JetAttachDatabase, JetOpenDatabase, JetCloseDatabase, and JetDetachDatabase |
| Code-specific boundary | the selected file is not a usable ESE database for this operation |
| First corrective direction | locate the correct database artifact and verify it with read-only tooling before attachment |
Creating an empty file is not a valid substitute for a missing or corrupted ESE database. Attachment is an instance relationship; opening a database returns a session-scoped database ID.
Comparison with adjacent failures
hrDatabaseNotFound | a valid database name or path did not resolve to an attached or existing database |
|---|---|
hrInvalidDatabaseId | the JET_DBID no longer identifies an open database in the supplied session |
hrDatabaseLocked | the database is locked against the requested access mode |
What to capture before retrying
A useful trace should preserve the first failing operation and the state of the database file, attachment state, JET_DBID ownership, and database lifecycle.
- Code-specific observation: inspect the file type, header, page size, provenance, and whether a log, checkpoint, or unrelated file was supplied.
- open tables, transactions, maintenance, and recovery activity using the database.
- the canonical database path and file identity.
- the instance attachment list plus every session-scoped JET_DBID.
Actions that can hide or worsen the problem
- Do not create an empty database at the expected path as a substitute for the missing or damaged artifact.
- Do not force detach or delete while owners and recovery state are unknown.
Operational response
- Freeze the failing request context and record
0xC8000404, the Jet API name, and the current instance/session ownership. - Verify the code-specific precondition: inspect the file type, header, page size, provenance, and whether a log, checkpoint, or unrelated file was supplied.
- Apply the targeted fix: locate the correct database artifact and verify it with read-only tooling before attachment.
- Before retrying the operation, reconcile attachment, open/closed state, file identity, and database header status.
- Add a regression test that reproduces the old failure and proves cleanup leaves no stale handles; then repeat the smallest read-only or disposable test that exercises the corrected precondition.
Developer-facing acceptance test
Build a focused test that reproduces it at the database file, attachment state, JET_DBID ownership, and database lifecycle layer. The corrected test should change only the decisive condition—the selected file is not a usable ESE database for this operation—and should prove that cleanup is safe if the call still fails.
Technical references
- JetCreateDatabase — used to verify the ESE object model, API ordering, or error family relevant to this HRESULT.
- JetDetachDatabase
- ESE files
- JET error codes
- Microsoft: JET_ERR enumeration
Looking for a different code? Search another status or error code.