| Previous | Next |
| hrPMRecDeleted | hrLogFileCorrupt |
hrFLDTooManySegments
State represented by this code
For hrFLDTooManySegments, this code narrows the investigation to one engine boundary and should not be flattened into a generic exception. The decisive boundary is an index key definition contains more segments than the legacy record manager supports.
The stored Value is 0xC8000191 (negative JET error -401; -401). The HRESULT carries failure severity, so output state must be treated according to the individual API contract. The legacy this result name comes from the Windows Directory Service backup/restore message header.
The first useful distinction is that this is a segment-count boundary; hrFLDKeyTooBig concerns the resulting key byte length. Start by preserve the full ordered segment list, sort directions, conditional columns, and the schema API that submitted it. That separates a reproducible incident from a later generic cleanup or service error.
Data for a reproducible incident
Preserve the first result before retries, cleanup, service restart, or file replacement changes the evidence. The diagnostic record should identify the exact API phase and the owner of every handle or artifact involved.
- Code-specific observation: preserve the full ordered segment list, sort directions, conditional columns, and the schema API that submitted it.
- Concurrent delete or migration owner: record it together with this result and the timestamp of the first occurrence.
- Key/bookmark and index: record it together with this result and the timestamp of the first occurrence.
- Transaction snapshot: record it together with this result and the timestamp of the first occurrence.
- Schema segment list: record it together with it and the timestamp of the first occurrence.
Objects and state involved
| Diagnostic layer | record lifetime and index key-definition constraints |
|---|---|
| Relevant API surface | cursor seeks, bookmarks, deletes, schema creation, and index maintenance |
| Code-specific boundary | an index key definition contains more segments than the legacy record manager supports |
| Narrow corrective direction | reduce the number of key columns or redesign the lookup around a smaller persisted key |
Record deletion is a normal concurrency outcome that must be distinguished from structural corruption., index segment count and key byte size are separate limits.
Actions that can make diagnosis worse
- do not remove arbitrary key columns without checking query semantics.
- do not reuse a stale bookmark without reseeking.
- do not discard the first lower-level Win32, RPC, or JET result merely because a later cleanup call returned a more familiar error.
Nearby ESE or AD backup states
It specifically means that this is a segment-count boundary; hrFLDKeyTooBig concerns the resulting key byte length. Related values below can appear in the same workflow but require a different response:
hrPMRecDeleted | a legacy page/record-manager path found that the target record had already been deleted |
|---|---|
hrFullBackupNotTaken | the caller requested an incremental backup without a completed full backup recorded as its baseline |
hrInvalidBackup | an incremental external backup was requested while circular logging prevents preservation of the required historical log range |
Keep the original constant and hexadecimal value in telemetry. Replacing it with “backup failed” or “database warning” removes the state information needed to select the next legal API call.
Next actions
- Record it,
0xC8000191, the API name, the current phase, and all live context or file owners. - Verify the decisive condition by preserve the full ordered segment list, sort directions, conditional columns, and the schema API that submitted it.
- Apply only the narrow correction: reduce the number of key columns or redesign the lookup around a smaller persisted key.
- After it, recreate any context invalidated by the failure; do not carry stale HBC, cursor, file, or restore-map state into the retry.
- repeat the smallest non-destructive test that reaches the same boundary, then verify both the return value and the resulting file, cursor, backup, or database state.
Acceptance criteria for a fix
Technical references
- ESE errors — API ordering, file semantics, warning/error interpretation, or recovery behavior relevant to it.
- JET_ERR enumeration
- Open-source ESE implementation
Looking for a different code? Search another status or error code.