| Previous | Next |
| hrColumnMaxTruncated | hrKeyChanged |
hrwrnDataHasChanged
Interpretation in the backup state machine
hrwrnDataHasChanged means the record or data image changed while the caller was using a prior observation.
The stored value is 0x8800064A (positive JET status 1610; 1610). 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_wrnDataHasChanged for the corresponding published JET condition.
The first useful distinction is that this is an optimistic-concurrency signal, not automatically physical corruption or a write conflict at the lock manager. Start by capturing bookmark, update sequence, transaction boundaries, before/after version identifiers, and which operation detected the change.
Start with these observations
- Code-specific observation: capture bookmark, update sequence, transaction boundaries, before/after version identifiers, and which operation detected the change.
Objects and state involved
| Diagnostic layer | record versioning and optimistic concurrency |
|---|---|
| Relevant API surface | record retrieval, prepared updates, bookmarks, transactions, and compare-before-write logic |
| Code-specific condition | the record or data image changed while the caller was using a prior observation |
| Narrow corrective direction | re-read under the intended transaction model and revalidate business predicates before applying an update |
ESE snapshot/version behavior can make a prior observation stale without corrupting the record. A caller must define whether to retry, merge, or reject when data changes.
Recovery or retry plan
- Record it,
0x8800064A, the API name, the current phase, and all live context or file owners. - Verify the condition by capturing bookmark, update sequence, transaction boundaries, before/after version identifiers, and which operation detected the change.
- Apply only the targeted fix: re-read under the intended transaction model and revalidate business predicates before applying an update.
Not the same as
It specifically means that this is an optimistic-concurrency signal, not automatically physical corruption or a write conflict at the lock manager. Related values below can appear in the same workflow but require a different response:
hrLogWriteFail | the write-ahead log could not durably accept a required record |
|---|---|
hrColumnSetNull | a column update resulted in a NULL value as an explicit outcome |
hrLogSequenceEnd | the legacy log generation namespace reached its maximum value |
Actions that can make diagnosis worse
- Do not classify every data-change warning as storage damage.
- Do not overwrite the newer record from a stale snapshot.
Acceptance criteria for a fix
A useful regression test should force the condition “the record or data image changed while the caller was using a prior observation”, call one documented API transition, and assert the exact HRESULT.
Technical references
- ESE transaction model — API ordering, file semantics, warning/error interpretation, or recovery behavior relevant to this HRESULT.
- ESE warning table
- Open-source ESE implementation
Looking for a different code? Search another status or error code.