| Previous | Next |
| hrOutOfSessions | hrTransTooDeep |
hrWriteConflict
Why this is more specific than the message text
hrWriteConflict means another session owns a conflicting write lock for the target record or page.
This is the legacy Directory Service backup/restore HRESULT form of JET_errWriteConflict (0xC800044E).
The key comparison is: hrSessionWriteConflict occurs between cursors in one session; this result is cross-session contention. The first useful observation is to capture the target key/bookmark, both session IDs, transaction ages, and lock acquisition order. This evidence shows whether the failure is nesting, ownership, cursor-local conflict, cross-session contention, or changed row state.
Related ESE conditions
hrTransTooDeep | the session exceeded the supported nesting depth of transaction save points |
|---|---|
hrerrDataHasChanged | optimistic cursor state no longer matches the row version expected by the operation |
hrSessionWriteConflict | two cursors in the same session attempted incompatible replacement of one record |
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 | another session owns a conflicting write lock for the target record or page |
| First corrective direction | rollback the losing transaction, apply bounded jittered retry, and keep the transaction body idempotent |
Nested ESE transactions are save points and still share the outer session context. Retries must re-read application preconditions because the visible row may have changed.
Data for a reproducible case
- Code-specific observation: capture the target key/bookmark, both session IDs, transaction ages, and lock acquisition order.
- the row version and business preconditions observed before the write.
- every begin, commit, and rollback for the exact JET_SESID.
- transaction depth, thread owner, cursor handles, and target bookmark or key.
Corrective workflow
- Freeze the failing request context and record
0xC800044E, the Jet API name, and the current instance/session ownership. - Verify the code-specific precondition: capture the target key/bookmark, both session IDs, transaction ages, and lock acquisition order.
- Apply the targeted fix: rollback the losing transaction, apply bounded jittered retry, and keep the transaction body idempotent.
- Before retrying the operation, reconcile transaction depth, lock release, row version, and application-level idempotency.
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.