| Previous | Next |
| hrCreateIndexFailed | hrwrnDataHasChanged |
hrColumnMaxTruncated
The exact condition reported here
hrColumnMaxTruncated means the requested maximum column length exceeded the supported limit and the engine reduced it.
The stored value is 0x880005E8 (positive JET status 1512; 1512). The HRESULT carries a warning, so the call may have useful output or a valid cursor state that must be inspected. Current ESE documentation uses JET_wrnColumnMaxTruncated for the corresponding published JET condition.
The first useful distinction is that this changes schema metadata; hrBufferTruncated concerns one retrieval buffer and does not redefine the column. Start by comparing the requested and effective maximum, column type, page size, code page, and API structure returned after creation.
Objects and state involved
| Diagnostic layer | partial schema creation and effective column/index definitions |
|---|---|
| Relevant API surface | compound table/column/index creation and schema inspection |
| Code-specific condition | the requested maximum column length exceeded the supported limit and the engine reduced it |
| Narrow corrective direction | read back the effective definition and reject the migration if application data can exceed it |
Compound schema APIs can report object-specific results rather than one all-or-nothing outcome. The effective schema returned by ESE is the contract the application must verify.
Adjacent conditions
This result specifically means that this changes schema metadata; hrBufferTruncated concerns one retrieval buffer and does not redefine the column. Related values below can appear in the same workflow but require a different response:
hrCreateIndexFailed | a compound table-creation operation could not complete one of its requested index definitions |
|---|---|
hrSeekNotEqual | a less-than-or-equal or greater-than-or-equal seek positioned the cursor without finding an exact key match |
hrLogFileCorrupt | ESE detected structural or checksum corruption while reading a transaction log |
Diagnostic record
- Code-specific observation: compare the requested and effective maximum, column type, page size, code page, and API structure returned after creation.
- Created object IDs: capture the value and timestamp from the first occurrence.
- Cleanup after partial success: capture the value and timestamp from the first occurrence.
- All schema descriptors and result fields: capture the value and timestamp from the first occurrence.
- Requested versus effective limits: capture the value and timestamp from the first occurrence.
Actions that can make diagnosis worse
- Do not assume rollback removed every partially created object.
- Do not deploy a schema whose effective limits were not read back.
Corrective path
- Record it,
0x880005E8, the API name, the current phase, and all live context or file owners. - Verify the condition by comparing the requested and effective maximum, column type, page size, code page, and API structure returned after creation.
- Apply only the targeted fix: read back the effective definition and reject the migration if application data can exceed it.
Acceptance criteria for a fix
A useful regression test should force the condition “the requested maximum column length exceeded the supported limit and the engine reduced it”, call one documented API transition, and assert the exact HRESULT.
Technical references
- ESE warning and error table — API ordering, file semantics, warning/error interpretation, or recovery behavior relevant to this HRESULT.
- JET_ERR enumeration
- Open-source ESE implementation
Looking for a different code? Search another status or error code.