| Previous | Next |
| hrOutOfBuffers | hrTooManyKeys |
hrTooManyIndexes
Interpretation in ESE terms
For hrTooManyIndexes, the diagnostic value comes from the specific ESE error family and the exact operation that returned it. The decisive boundary is a table schema attempted to exceed the supported number of indexes.
This result is the legacy Directory Service backup/restore HRESULT form of the ESE condition normally written as JET_errTooManyIndexes. Preserve the original value 0xC80003F7 when a wrapper also exposes a signed JET_ERR.
The key comparison for this HRESULT is this: hrTooManyOpenIndexes is runtime descriptor exhaustion; this code is a schema-count limit. The first useful observation is to enumerate current indexes, conditional indexes, and the migration step adding the next definition. This this result evidence separates index schema, current-index cursor state, key construction, and duplicate data.
The ESE objects in play
| Diagnostic layer | B-tree index definition, key construction, uniqueness, and current-index cursor state |
|---|---|
| Typical API surface | JetCreateIndex, JetDeleteIndex, JetSetCurrentIndex, JetMakeKey, JetSeek, and JetSetIndexRange |
| Code-specific boundary | a table schema attempted to exceed the supported number of indexes |
| First corrective direction | remove redundant indexes or redesign the schema before replaying the migration |
Clustered, primary, and unique properties must be interpreted from the actual index flags., index schema and runtime key-building state are separate diagnostic layers.
Comparison with adjacent failures
For this HRESULT, hrTooManyOpenIndexes is runtime descriptor exhaustion; this code is a schema-count limit. The following neighboring results belong to the same broad subsystem but mark different boundaries:
hrNullKeyDisallowed | an index definition or inserted row produces a null key where the index contract forbids it |
|---|---|
hrTooManyKeys | an index definition contains more key segments than the engine accepts |
hrNoCurrentIndex | the cursor operation requires an active index but none is selected or available |
Keep this result in the incident record; replacing it with “database error” hides whether the next step is handle renewal, schema correction, lock reconciliation, or file preservation.
What to capture before retrying
A useful trace for this HRESULT should preserve the first failing operation and the state of the B-tree index definition, key construction, uniqueness, and current-index cursor state.
- Code-specific observation: enumerate current indexes, conditional indexes, and the migration step adding the next definition.
- the raw index key definition, flags, locale, and conditional columns; associate it with this result rather than with a later generic exception.
- the current index plus every JetMakeKey segment and grbit; associate it with it rather than with a later generic exception.
- the encoded key and existing row when uniqueness is involved; associate it with it rather than with a later generic exception.
Log lengths, hashes, IDs, flags, and redacted samples where appropriate.
Actions that can hide or worsen the problem
- do not drop or rebuild an index before checking uniqueness and table-layout dependencies.
- do not treat a key-construction or duplicate-key result as database-file corruption.
Operational response
- Freeze the failing request context and record it,
0xC80003F7, the Jet API name, and the current instance/session ownership. - Verify the code-specific precondition: enumerate current indexes, conditional indexes, and the migration step adding the next definition.
- Apply the narrow correction: remove redundant indexes or redesign the schema before replaying the migration.
- Before retrying it, reconcile index definition, selected cursor index, and key or uniqueness outcome.
- confirm both the returned HRESULT and the resulting database, cursor, or file state; then add a regression test that forces the old boundary and proves cleanup leaves no stale handles.
Developer-facing acceptance test
Build a focused test that reproduces it at the B-tree index definition, key construction, uniqueness, and current-index cursor state layer. Record the precondition, execute one API call, and assert the HRESULT plus the resulting handle and transaction state. The corrected it test should change only the decisive condition—a table schema attempted to exceed the supported number of indexes—and should prove that cleanup is safe if the call still fails.
Technical references
- JetCreateIndex — used to verify the ESE object model, API ordering, or error family relevant to it.
- JetMakeKey
- JetSeek
- ESE source repository
- Microsoft: JET_ERR enumeration
Looking for a different code? Search another status or error code.