| Previous | Next |
| hrUpdateNotPrepared | hrTooManySorts |
hrerrDataHasChanged
Locate the failure in the Jet call chain
hrerrDataHasChanged means optimistic cursor state no longer matches the row version expected by the operation.
This is the legacy Directory Service backup/restore HRESULT form of JET_errDataHasChanged (0xC800064B).
The key comparison is: hrWriteConflict is lock acquisition contention; this result can be detected as changed data without that lock path. The first useful observation is to capture bookmark, transaction snapshot, preceding warning/status, and the writer that changed the row. This evidence shows whether the failure is nesting, ownership, cursor-local conflict, cross-session contention, or changed row state.
The ESE objects in play
| Diagnostic layer | JET_SESID transaction depth, row versions, and write ownership |
|---|---|
| Typical API surface | JetBeginSession, JetBeginTransaction, JetCommitTransaction, JetRollback, and update APIs |
| Code-specific condition | optimistic cursor state no longer matches the row version expected by the operation |
| First corrective direction | refresh the row, re-evaluate business preconditions, and retry only through an idempotent transaction |
Retries must re-read application preconditions because the visible row may have changed. Each begin must be matched by commit or rollback on the same session.
Questions the logs must answer
- Code-specific observation: capture bookmark, transaction snapshot, preceding warning/status, and the writer that changed the row.
- the row version and business preconditions observed before the write; associate it with this result rather than with a later generic exception.
- every begin, commit, and rollback for the exact JET_SESID.
- transaction depth, thread owner, cursor handles, and target bookmark or key.
Response and verification
- Freeze the failing request context and record
0xC800064B, the Jet API name, and the current instance/session ownership. - Verify the code-specific precondition: capture bookmark, transaction snapshot, preceding warning/status, and the writer that changed the row.
- Apply the targeted fix: refresh the row, re-evaluate business preconditions, and retry only through an idempotent transaction.
- Before retrying the operation, reconcile transaction depth, lock release, row version, and application-level idempotency.
Distinguishing signals
hrWriteConflict | another session owns a conflicting write lock for the target record or page |
|---|---|
hrInTransaction | an operation that requires transaction level zero was invoked while the session has an active transaction |
hrTransTooDeep | the session exceeded the supported nesting depth of transaction save points |
Actions that can hide or worsen the problem
- Do not blindly retry a non-idempotent update after a conflict.
- Do not share a session with an open transaction across unrelated threads or requests.
Technical references
Looking for a different code? Search another status or error code.