Informix Error -178

Reasons / Common Causes

-178 is a designed safety mechanism, not a bug: once a request to change a database's logging status has been made, the database is locked from access until a level-0 archive completes for every storage space it uses. This ensures the database is actually recoverable under its new logging mode before anyone can use it — skipping this would leave a window where the database claims a logging mode it can't yet back up to.

1. A logging-mode change request was issued (starting logging on a previously unlogged database, or changing to ANSI mode, for example), putting the database into this locked, pending state.
2. An application or user attempting to access the database during this window, before the required archive has actually completed.
3. The required level-0 archive not being triggered promptly after the logging-mode-change request — leaving the database locked longer than necessary because nobody realized an archive still needed to run.
4. Unfamiliarity with the requirement itself — a team changing logging mode without realizing it necessitates a fresh level-0 archive before the database becomes usable again.
5. An archive that's running or has run, but doesn't cover all the storage spaces the database uses — a partial or outdated archive schedule that doesn't satisfy the full requirement, leaving the lock in place even after some backup activity has occurred.

Solutions / Resolution

1. Run (or complete) a level-0 archive covering every storage space the database uses. This is the direct, required action to clear the lock, per the official guidance.
2. If an archive is already scheduled or running, wait for it to complete rather than repeatedly retrying access.
3. Schedule the required level-0 archive as part of the same maintenance window as any planned logging-mode change, so applications aren't caught by surprise by this lock afterward.
4. Confirm the archive genuinely covers all storage spaces the database uses, not just some — a partial archive won't satisfy the requirement and the lock will persist.
5. Document this requirement in runbooks for anyone performing logging-mode changes — the lock exists by design to guarantee recoverability under the new mode, not as an incidental side effect to work around.

Examples

The expected sequence

-- Requesting a logging-mode change
START DATABASE mydb WITH LOG;
-- database is now locked pending a level-0 archive

-- Run the required archive covering all storage spaces mydb uses
ontape -s -L 0
-- once complete, the lock clears and mydb becomes accessible again

A partial archive that doesn't clear the lock

-- An archive job only covers some of the storage spaces mydb uses
-- (perhaps a legacy schedule that predates a newly added dbspace)
ontape -s -L 0
-- -178 persists: the archive didn't cover every storage space
-- the database actually uses

Confirming the archive's scope matches the database's full storage footprint is the fix here, not simply running the archive again unchanged.

Diagnostic Checks

1. Confirm a logging-mode-change request is actually pending for the database in question.
2. Check whether a level-0 archive covering all the database's storage spaces has completed since the request was made.
3. Check archive status or progress if one is currently in progress.

Related Errors / Related Topics

• -147 — "ISAM error: archive in progress." Related through the same general archive-centric family, though -147 is about other operations being blocked by an archive, while -178 is a database being locked pending one.
• -174 — "ISAM error: An error has occurred during archive back up." Worth checking if the required level-0 archive itself is failing — that would explain why -178's lock never clears.

Confirm the level-0 archive actually covers every storage space the database uses — a partial archive is a common reason this lock persists longer than expected.