| Previous | Next |
| hrKeyChanged | WEP_E_NOT_PROVISIONED_ON_ALL_VOLUMES |
hrFileOpenReadOnly
Operational meaning
hrFileOpenReadOnly means the database file was opened in read-only mode and the resulting handle cannot support logged updates.
The stored value is 0x88000715 (positive JET status 1813; 1813). 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_wrnFileOpenReadOnly for the corresponding published JET condition.
The first useful distinction is that read-only access is an established mode, distinct from access denied while opening or a later disk-write failure. Start by capturing attach/open flags, file attributes, volume permissions, instance recovery mode, and the first operation requiring a write.
Before altering files or retrying
- Code-specific observation: capture attach/open flags, file attributes, volume permissions, instance recovery mode, and the first operation requiring a write.
Comparison points
It specifically means that read-only access is an established mode, distinct from access denied while opening or a later disk-write failure. Related values below can appear in the same workflow but require a different response:
hrDatabaseAttached | the database was already attached to the instance when another attach operation was requested |
|---|---|
hrInvalidParam | a legacy Directory Service backup/restore call rejected one or more arguments before advancing its context |
hrIncrementalBackupDisabled | the database lineage no longer permits the requested incremental backup and requires a new full baseline |
Objects and state involved
| Diagnostic layer | database attachment/open mode and ownership by an ESE instance |
|---|---|
| Relevant API surface | attach, open, initialization, recovery, and instance lifecycle operations |
| Code-specific condition | the database file was opened in read-only mode and the resulting handle cannot support logged updates |
| Narrow corrective direction | keep the workflow read-only or reopen through the owning application with a writable, recoverable log configuration |
Attachment belongs to an instance, while an open database ID belongs to a session. Read-only and already-attached warnings can be valid operating modes but constrain later calls.
Recommended handling
- Record it,
0x88000715, the API name, the current phase, and all live context or file owners. - Verify the condition by capturing attach/open flags, file attributes, volume permissions, instance recovery mode, and the first operation requiring a write.
- Apply only the targeted fix: keep the workflow read-only or reopen through the owning application with a writable, recoverable log configuration.
Acceptance criteria for a fix
A useful regression test should force the condition “the database file was opened in read-only mode and the resulting handle cannot support logged updates”, call one documented API transition, and assert the exact HRESULT.
Actions that can make diagnosis worse
- Do not attempt logged writes through a read-only path.
- Do not detach a database merely to silence a warning without checking owners.
Technical references
- ESE files and lifecycle — API ordering, file semantics, warning/error interpretation, or recovery behavior relevant to this HRESULT.
- JetInit and recovery
- ESE warning table
- Microsoft JET_ERR enumeration
Looking for a different code? Search another status or error code.