| Previous | Next |
| hrSessionWriteConflict | hrDatabaseDuplicate |
hrInTransaction
Why this is more specific than the message text
hrInTransaction means an operation that requires transaction level zero was invoked while the session has an active transaction.
This is the legacy Directory Service backup/restore HRESULT form of JET_errInTransaction (0xC8000454).
The key comparison is: hrNotInTransaction is the opposite precondition and requires an active transaction. The first useful observation is to capture transaction nesting depth and the API that must run outside it. This evidence shows whether the failure is nesting, ownership, cursor-local conflict, cross-session contention, or changed row state.
Related ESE conditions
hrerrDataHasChanged | optimistic cursor state no longer matches the row version expected by the operation |
|---|---|
hrInvalidSesid | the JET_SESID is stale, foreign to the instance, or otherwise invalid |
hrWriteConflict | another session owns a conflicting write lock for the target record or page |
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 | an operation that requires transaction level zero was invoked while the session has an active transaction |
| First corrective direction | commit or rollback to level zero before the operation, then begin a new transaction for later work |
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 transaction nesting depth and the API that must run outside it.
- 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.
- the row version and business preconditions observed before the write.
Corrective workflow
- Freeze the failing request context and record
0xC8000454, the Jet API name, and the current instance/session ownership. - Verify the code-specific precondition: capture transaction nesting depth and the API that must run outside it.
- Apply the targeted fix: commit or rollback to level zero before the operation, then begin a new transaction for later work.
- 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.