Informix Error -124

Reasons / Common Causes

-124 is a transaction-lifecycle sequencing bug: something tried to end a transaction (COMMIT WORK/ROLLBACK WORK, or the C-ISAM iscommit()/isrollback()) without a matching BEGIN WORK/isbegin() having run first on that same connection or session.

1. A straightforward missing BEGIN WORK before a COMMIT/ROLLBACK — the direct case the official text describes.
2. A double-commit bug — a transaction already ended once, and a second COMMIT/ROLLBACK fires against the same logical unit of work without a new BEGIN WORK in between. Common in error-handling code that runs both a success-path commit and a cleanup-path commit/rollback without checking whether one already happened.
3. Unconditional cleanup code that always issues ROLLBACK WORK "just in case," even on code paths where no transaction was ever started — a defensive pattern that backfires the moment it runs somewhere a transaction genuinely wasn't begun.
4. Connection-pooling state confusion — a connection returned to the pool without a definitive commit or rollback, then checked out again by different code that assumes fresh state; either the reusing code or leftover cleanup logic ends up trying to end a transaction that (from this connection's current perspective) was never begun.
5. Autocommit-mode assumptions not matching the actual session configuration — code written assuming explicit transaction control issuing a COMMIT in a context where no explicit BEGIN WORK was actually needed or issued.
6. A driver or ORM layer's internal transaction-state tracking drifting out of sync with the actual server-side state — it believes a transaction is open and sends a commit/rollback the server doesn't agree was ever started.
7. Naive nested transaction attempts — code assuming nested BEGIN WORK/COMMIT pairs work like nested function calls, when the product's actual mechanism for that (savepoints) works differently.

Solutions / Resolution

1. Pair every COMMIT/ROLLBACK with a preceding BEGIN WORK on the same connection — review the exact call sequence rather than assuming it's correct.
2. Guard "just in case" cleanup rollbacks — track explicitly whether a transaction was actually started before attempting to end one in error-handling or cleanup code, rather than issuing an unconditional ROLLBACK WORK on every exit path.
3. Prevent double-commit bugs structurally — give each unit of work a single, well-defined transaction lifecycle so success-path and cleanup-path logic can't both attempt to end the same transaction.
4. For connection-pooled applications, only return a connection to the pool after a definitive commit or rollback (never mid-transaction), and explicitly reset or verify transaction state when a connection is checked out for reuse.
5. Reconcile ORM/driver transaction-state tracking against actual server-side behavior if the mismatch appears to originate in that layer rather than in application code directly.
6. Use the product's actual savepoint mechanism if nested transaction-like semantics are genuinely needed, rather than attempting naive nested BEGIN/COMMIT pairs the engine doesn't support that way.

Examples

The straightforward missing BEGIN WORK

COMMIT WORK;
-- -124: no BEGIN WORK preceded this on the current session

The double-commit bug

BEGIN WORK;
INSERT INTO orders VALUES (...);
COMMIT WORK;              -- transaction ends here, successfully

-- Later in the same function's cleanup/error-handling path,
-- unconditionally executed regardless of the success above:
ROLLBACK WORK;             -- -124: nothing has been begun since the commit

The fix isn't in the ROLLBACK WORK itself — it's that the cleanup path needs to know the transaction already ended successfully and skip the rollback entirely.

Connection pool reuse without a clean handoff

-- Connection checked out, BEGIN WORK issued, application error occurs
-- before COMMIT/ROLLBACK runs; connection is returned to the pool anyway
-- (a bug in the pooling layer's error handling)

-- Connection checked out again by unrelated code, which assumes a
-- fresh connection and issues its own BEGIN WORK... but pool-level
-- cleanup logic elsewhere also tries to ROLLBACK WORK on checkout,
-- racing against the new code's own transaction state

Pooling bugs like this are diagnosed by tracing the connection's actual transaction state across checkout/checkin boundaries, not by looking at either piece of application code in isolation.

Diagnostic Checks

1. Review the exact call sequence on the affected connection/session leading up to the failing COMMIT/ROLLBACK — was there a BEGIN WORK immediately (or at all) before it in this session's history?
2. Check autocommit-mode assumptions against the actual session configuration in use.
3. For connection-pooled applications, review checkout/checkin logic for how transaction state is verified or reset when a connection changes hands.
4. Review error/cleanup-handling code paths for unconditional commit/rollback calls that don't check whether a transaction was actually started first.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family.
• -122 — "ISAM error: transaction not available." The configuration-level sibling — -122 means the database/file doesn't support transactions at all; -124 means transactions are supported, but this specific one was never begun before something tried to end it.

If -124 appears in cleanup or error-handling code rather than the main success path, check for an unconditional commit/rollback there first — that's the most common actual source.