| Previous | Next |
| hrRecordTooBig | hrInvalidDatabase |
hrTooManyOpenDatabases
Interpretation in ESE terms
hrTooManyOpenDatabases means a session or instance exceeded the number of simultaneously open databases.
This is the legacy Directory Service backup/restore HRESULT form of JET_errTooManyOpenDatabases (0xC8000403).
The key comparison is: hrTooManyAttachedDatabases concerns attachments; an attached database need not be open in a session. The first useful observation is to inventory JET_DBID ownership and match every successful open with its close path. This evidence identifies the exhausted pool so a leak, long transaction, concurrency spike, and hard capacity limit are not confused.
The ESE objects in play
| Diagnostic layer | bounded engine, process, and storage resources |
|---|---|
| Typical API surface | instance system parameters, sessions, cursors, temporary tables, database attachment, and file growth |
| Code-specific condition | a session or instance exceeded the number of simultaneously open databases |
| First corrective direction | close idle database handles and bound request-scoped opens |
A retry without closing owners or adding capacity often repeats the same failure and increases load. Resource codes should be tied to the exact exhausted pool rather than treated as generic low memory.
Comparison with adjacent failures
hrTooManyAttachedDatabases | the instance reached its attached-database limit |
|---|---|
hrTooManyOpenIndexes | the engine exhausted index descriptor blocks through excessive open/index-selection activity |
hrTooManyActiveUsers | the engine reached its active-user or concurrent-session workload limit |
What to capture before retrying
- relevant JET_param values and process or system capacity at first failure.
- the oldest transaction, longest-held cursor, or file growth operation retaining the resource.
- live resource counts grouped by session and request owner.
Actions that can hide or worsen the problem
- Do not raise limits before checking ownership and release paths.
- Do not create a retry storm while the exhausted resource remains unavailable.
Operational response
- Freeze the failing request context and record
0xC8000403, the Jet API name, and the current instance/session ownership. - Apply the targeted fix: close idle database handles and bound request-scoped opens.
- Before retrying the operation, reconcile resource counts, owner cleanup, and capacity after the correction.
Technical references
Looking for a different code? Search another status or error code.