Informix Error -188

Reasons / Common Causes

-188 is a consistency-protection rule for Data Replication (DR): transaction logging can't be added to a database on a DR primary while DR is actively running. Changing a database's logging status mid-replication would break the consistency guarantee DR depends on between the primary and secondary.

1. Attempting to add transaction logging to a database on a DR primary while DR is active — the direct, disallowed operation.
2. Wanting to enable logging on a previously unlogged database that's part of an active DR pair, without first realizing DR needs to be paused or disabled before this specific change.
3. Confusion about the required multi-step process — disable DR, add logging, then re-establish DR via a fresh level-0 archive and a physical restore on the secondary, then restart DR — attempted out of order or with a step skipped.
4. Planning this change on a system where DR is treated as always-on, without accounting for the brief, necessary interruption this process requires.

Solutions / Resolution

Follow the documented sequence exactly, in order:

1. Disable DR first, before attempting to add transaction logging.
2. Add transaction logging using the normal process (START DATABASE ... WITH LOG or equivalent) — remembering, as with -122/-128, to back up first.
3. Re-establish DR: create a level-0 archive on the primary, then perform a physical restore on the secondary. This rebuilds the secondary from a fresh, consistent baseline that reflects the database's new logging state.
4. Restart DR after re-establishing it. The official guidance emphasizes this step is essential to prevent inconsistencies between primary and secondary that could otherwise cause DR failures later.
5. Plan for the DR interruption window explicitly as part of any logging-mode change on a DR-paired primary — this isn't a quick, non-disruptive operation, so schedule it accordingly.
6. Don't improvise a shortcut through this sequence — the official guidance's specific ordering exists to avoid exactly the inconsistency it warns about.

Examples

The required sequence

-- 1. Disable DR
onmode -d standard <secondary>   -- or the equivalent DR-disable command

-- 2. Add transaction logging
ontape -s -L 0                    -- back up first
START DATABASE mydb WITH LOG;

-- 3. Re-establish DR
ontape -s -L 0                    -- fresh level-0 archive on the primary
-- perform a physical restore on the secondary from this archive

-- 4. Restart DR
onmode -d DRAUTO <secondary>      -- or the equivalent DR-restart command

Skipping step 3 (re-establishing DR from a fresh baseline) after changing logging status is what the official guidance's warning about inconsistency is specifically about — the secondary's existing state no longer matches a primary whose logging configuration just changed.

Diagnostic Checks

1. Confirm DR status (active or inactive) on the primary before and during the attempted logging change.
2. Review the process being followed against the documented sequence to identify a skipped or out-of-order step, if this recurs unexpectedly.

Related Errors / Related Topics

• -178 — "ISAM error: Database is locked; pending change to logging mode." The closest sibling — both concern the archive requirement tied to changing a database's logging status, though -178 is the general case and -188 is specific to a DR-paired primary.
• -122 — "ISAM error: transaction not available." The general transaction-logging- availability topic this fits into.

Follow the documented four-step sequence in full — disabling DR, adding logging, re-establishing DR from a fresh archive, and restarting DR — rather than attempting to shortcut any step.