| Previous | Next |
| hrDatabaseInUse | hrDatabaseInvalidName |
hrDatabaseNotFound
The object and state that matter
hrDatabaseNotFound means a valid database name or path did not resolve to an attached or existing database.
This is the legacy Directory Service backup/restore HRESULT form of JET_errDatabaseNotFound (0xC80004B3).
The key comparison is: hrInvalidDatabaseId is a bad handle; this code is a lookup failure by database identity. The first useful observation is to capture the canonical path, attachment list, working directory, case/normalization, and file existence. This evidence separates file identity, attachment, open-handle ownership, lock state, and structural validity.
Minimum useful trace
- Code-specific observation: capture the canonical path, attachment list, working directory, case/normalization, and file existence.
- the canonical database path and file identity; associate it with this result rather than with a later generic exception.
- the instance attachment list plus every session-scoped JET_DBID; associate it with this result rather than with a later generic exception.
- open tables, transactions, maintenance, and recovery activity using the database.
How to avoid a false diagnosis
hrDatabaseLocked | the database is locked against the requested access mode |
|---|---|
hrInvalidDatabase | the selected file is not a usable ESE database for this operation |
hrDatabaseInvalidPages | the requested initial or maximum database size is not a valid page count |
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 condition | a valid database name or path did not resolve to an attached or existing database |
| First corrective direction | locate or attach the correct database instead of creating an empty replacement automatically |
Attachment is an instance relationship; opening a database returns a session-scoped database ID. Close and detach are separate lifecycle steps and can fail for different outstanding owners.
Safe recovery sequence
- Freeze the failing request context and record
0xC80004B3, the Jet API name, and the current instance/session ownership. - Verify the code-specific precondition: capture the canonical path, attachment list, working directory, case/normalization, and file existence.
- Apply the targeted fix: locate or attach the correct database instead of creating an empty replacement automatically.
- Before retrying the operation, reconcile attachment, open/closed state, file identity, and database header status.
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.
Technical references
Looking for a different code? Search another status or error code.