| Previous | Next |
| hrNoIdleActivity | hrColumnSetNull |
hrNoWriteLock
Operational meaning
hrNoWriteLock means the operation reached transaction level zero without the write lock it expected to observe.
The stored value is 0x8800042B (positive JET status 1067; 1067). 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_wrnNoWriteLock for the corresponding published JET condition.
The first useful distinction is that the warning is about absent ownership, not necessarily a competing writer or deadlock. Start by capturing transaction nesting, cursor ownership, update preparation state, and the call that requested lock-sensitive behavior.
Before altering files or retrying
- Code-specific observation: capture transaction nesting, cursor ownership, update preparation state, and the call that requested lock-sensitive behavior.
Comparison points
It specifically means that the warning is about absent ownership, not necessarily a competing writer or deadlock. Related values below can appear in the same workflow but require a different response:
hrRestoreInProgress | another restore context already owns the Directory Service restore workflow |
|---|---|
hrLogBufferTooSmall | the available recovery log buffer cannot hold the log record or sector data required for replay |
hrExistingLogFileIsNotContiguous | the log sequence already present in the target path contains a generation gap required by recovery |
Objects and state involved
| Diagnostic layer | transaction nesting, update preparation, and lock ownership |
|---|---|
| Relevant API surface | transaction begin/commit/rollback, cursor updates, write locks, and session-scoped handles |
| Code-specific condition | the operation reached transaction level zero without the write lock it expected to observe |
| Narrow corrective direction | re-establish the documented transaction and update sequence instead of assuming a lock can be inherited across handles |
Locks and prepared updates are scoped to engine objects and transaction state. Absence of a lock is not identical to a conflict with another writer.
Recommended handling
- Record it,
0x8800042B, the API name, the current phase, and all live context or file owners. - Verify the condition by capturing transaction nesting, cursor ownership, update preparation state, and the call that requested lock-sensitive behavior.
- Apply only the targeted fix: re-establish the documented transaction and update sequence instead of assuming a lock can be inherited across handles.
Acceptance criteria for a fix
A useful regression test should force the condition “the operation reached transaction level zero without the write lock it expected to observe”, call one documented API transition, and assert the exact HRESULT.
Actions that can make diagnosis worse
- Do not retry an update before rebuilding the required transaction state.
- Do not share session or cursor ownership implicitly across threads.
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.