| Previous | Next |
| hrInvalidSesid | hrInTransaction |
hrSessionWriteConflict
Where the operation crossed the contract
hrSessionWriteConflict means two cursors in the same session attempted incompatible replacement of one record.
This is the legacy Directory Service backup/restore HRESULT form of JET_errSessionWriteConflict (0xC8000453).
The key comparison is: hrWriteConflict usually involves another session; this code exposes conflicting work inside one session. The first useful observation is to record both cursor handles, prepared update modes, bookmark, and order of JetPrepareUpdate calls. This evidence shows whether the failure is nesting, ownership, cursor-local conflict, cross-session contention, or changed row state.
Reconstruct the engine state
- Code-specific observation: record both cursor handles, prepared update modes, bookmark, and order of JetPrepareUpdate calls.
- every begin, commit, and rollback for the exact JET_SESID; associate it with this result rather than with a later generic exception.
- transaction depth, thread owner, cursor handles, and target bookmark or key; associate it with this result rather than with a later generic exception.
- the row version and business preconditions observed before the write.
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 | two cursors in the same session attempted incompatible replacement of one record |
| First corrective direction | serialize same-row updates within the session or use separate intentional transactions |
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.
Repair without destroying evidence
- Freeze the failing request context and record
0xC8000453, the Jet API name, and the current instance/session ownership. - Verify the code-specific precondition: record both cursor handles, prepared update modes, bookmark, and order of JetPrepareUpdate calls.
- Apply the targeted fix: serialize same-row updates within the session or use separate intentional transactions.
- Before retrying the operation, reconcile transaction depth, lock release, row version, and application-level idempotency.
Do not collapse these codes together
hrNotInTransaction | the operation requires a transaction but the supplied session has no active save point |
|---|---|
hrTransTooDeep | the session exceeded the supported nesting depth of transaction save points |
hrInvalidSesid | the JET_SESID is stale, foreign to the instance, or otherwise invalid |
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.