| Previous | Next |
| hrerrDataHasChanged | hrInvalidOnSort |
hrTooManySorts
Interpretation in ESE terms
hrTooManySorts means temporary sort resources are exhausted by concurrent or unreleased sort operations.
This is the legacy Directory Service backup/restore HRESULT form of JET_errTooManySorts (0xC80006A5).
The key comparison is: hrTooManyOpenIndexes concerns index descriptors; this code is temporary sort work. The first useful observation is to count temporary tables/sorts, cursor lifetimes, result sizes, and temp database pressure. 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 | temporary sort resources are exhausted by concurrent or unreleased sort operations |
| First corrective direction | close completed sorts, bound concurrency, and stream/filter earlier when possible |
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
hrTooManyOpenTables | the workload exhausted open table/cursor capacity |
|---|---|
hrVersionStoreOutOfMemory | the version store cannot retain more transactional versions under current workload and limits |
hrTooManyOpenIndexes | the engine exhausted index descriptor blocks through excessive open/index-selection activity |
What to capture before retrying
- Code-specific observation: count temporary tables/sorts, cursor lifetimes, result sizes, and temp database pressure.
- live resource counts grouped by session and request owner.
- 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.
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
0xC80006A5, the Jet API name, and the current instance/session ownership. - Verify the code-specific precondition: count temporary tables/sorts, cursor lifetimes, result sizes, and temp database pressure.
- Apply the targeted fix: close completed sorts, bound concurrency, and stream/filter earlier when possible.
- Before retrying the operation, reconcile resource counts, owner cleanup, and capacity after the correction.
Technical references
- JET_param enumeration.
- Transactions and save points
- ESE files and storage paths
- ESE source repository
- Microsoft: JET_ERR enumeration
Looking for a different code? Search another status or error code.