Informix Error -122

Reasons / Common Causes

-122 means something asked to mark the start or end of a transaction, but the database or file isn't configured for transaction logging at all — there's no log for a BEGIN WORK/COMMIT/ ROLLBACK (or the C-ISAM equivalent) to write to.

For C-ISAM programs:

1. The file was opened without the ISTRANS parameter. Transaction marking calls require the file to have been opened specifically for logged access; without ISTRANS in the isopen() call, there's nothing for a transaction-boundary call to act on.

For SQL products:

2. The database itself doesn't support transaction logging — it was created (or remains) as an unlogged database, and explicit transaction statements have no logging mechanism to record against.
3. Logging was previously enabled and later disabled, without the application code being updated to match — code that assumes transactions are available continues issuing BEGIN WORK/COMMIT against a database that no longer supports them.
4. An environment mismatch — application code written and tested against a logged database, then deployed against a differently configured (unlogged) instance, whether a different customer environment, a different deployment stage, or a database that was copied without preserving its logging mode.
5. A database copied or migrated without carrying over its logging configuration — created without logging by default and never explicitly upgraded.

Solutions / Resolution

For C-ISAM programs:

1. Include ISTRANS in the isopen() call for any file that needs transaction support — review the calls in question and add the flag.

For SQL products:

2. Have the database administrator enable logging for the database, or use START DATABASE to begin transaction logging, as documented.
3. Critical sequencing point from the official guidance: logging should only start immediately after the database has been fully backed up. Enabling logging without a fresh backup first leaves the database in a state where logging is active but there's no baseline to restore from if it's ever needed — don't treat "enable logging" as a standalone step; treat "backup, then enable logging" as one procedure.
4. Standardize logging configuration across environments so application code's transaction assumptions hold everywhere it runs — check this as part of environment parity/deployment verification rather than discovering a mismatch via -122 in production.
5. If code genuinely needs to run against both logged and unlogged databases, detect and branch explicitly rather than assuming transactions are always available.
6. After any database copy or migration, verify the logging mode carried over as expected (or was deliberately reconfigured), rather than assuming it matches the source.

Examples

Missing ISTRANS in C-ISAM

int fd = isopen("ledger", ISINPUT | ISOUTPUT);   /* no ISTRANS */
isbegin();       /* -122: this file wasn't opened for logged access */

Fix:

int fd = isopen("ledger", ISINPUT | ISOUTPUT | ISTRANS);
isbegin();       /* now valid */

Explicit transactions against an unlogged database

DATABASE mydb;
BEGIN WORK;
-- -122: mydb has no transaction logging enabled

The correct sequence, per the official guidance's ordering:

-- 1. Back up the database fully first
ontape -s -L 0
-- 2. Then enable logging
START DATABASE mydb WITH LOG;    -- or the DBA-driven equivalent
-- 3. Now explicit transactions work
BEGIN WORK;
COMMIT WORK;

The environment mismatch

Application code developed and tested against a logged staging database works correctly there, then fails with -122 the first time it runs against a customer's unlogged production database — nothing in the code changed; the target database's configuration is simply different from what was assumed during development.

Diagnostic Checks

1. Check whether the database has logging enabled:

   SELECT is_logging FROM sysmaster:sysdatabases WHERE name = 'mydb';
   

   or

   onstat -d
   

2. For C-ISAM, review the isopen() call for the failing file and confirm whether ISTRANS is included.
3. Compare configuration across environments if -122 appeared in one environment but not another running the same code.
4. Review database creation/migration history for whether logging was ever explicitly enabled, and whether a copy or migration might have reset that configuration.

Related Errors / Related Topics

• -118 — "ISAM error: cannot read log record." A different failure mode against the log — -118 assumes logging exists but a specific record can't be read; -122 is what happens when logging isn't configured to exist at all.
• -120 — "ISAM error: cannot open log file." Also log-related, but an OS-level access problem rather than a configuration one — -122 means there's no log to begin with, by design, not that an existing log couldn't be reached.

Before enabling logging to fix -122, make sure a full backup happens first — per the official guidance, that sequencing is not optional, it's what makes logging actually useful once enabled.