Informix Error -190

Reasons / Common Causes

-190 means the engine's transaction table — which tracks currently active transactions — has no free slots left. Like -134 (locks) and -141 (open tblspaces), this is a concurrency-driven capacity ceiling, and the same "genuine peak load vs. a leak" distinction matters for deciding what to do about it.

1. Too many concurrent transactions active at once, exceeding the engine's transaction table capacity — a genuine peak-concurrency condition.
2. Long-running transactions holding a transaction-table slot for an extended time, reducing available slots for new transactions even without an unusually high total session count.
3. Transaction leaks — transactions started but never properly committed or rolled back, due to an application bug or a crashed session that wasn't cleaned up promptly — accumulating and consuming slots indefinitely.
4. Transaction table capacity underprovisioned for the workload's actual peak concurrency.

Solutions / Resolution

1. Check the transaction table directly, per the official guidance:

   onstat -x
   

   This is the first step, always — it shows current usage and, critically, how long individual transactions have been open.
2. Distinguish genuine capacity pressure from a leak. A transaction table full of many long-running or seemingly orphaned transactions points at a leak or cleanup gap; a table full of many short-lived, actively-progressing transactions points at genuine peak-concurrency capacity pressure.
3. If it's a genuine capacity issue, consult the Administrator's Guide for the relevant configuration parameter governing transaction table size for your version, and increase it — this typically requires the same reinitialization discipline as other ONCONFIG-driven capacity ceilings in this range.
4. If leaks or orphaned transactions are found, investigate and fix the application code paths not properly committing or rolling back (especially on error paths), and address any gap in crashed-session cleanup.
5. Shorten long-running transactions where possible, freeing slots sooner rather than holding them for longer than the actual work requires.
6. Monitor transaction table usage over time to catch approaching the ceiling before it causes a hard failure.

Examples

Checking the transaction table

onstat -x

Review both the count of active transactions and, importantly, how long each has been open — a handful of transactions open for hours is a very different situation from many transactions each open for milliseconds.

The leak pattern

begin_transaction();
if (validate_input() < 0) {
    return -1;              /* leaked: transaction never committed or rolled back */
}
commit_transaction();       /* only reached on the success path */

Every call taking the validation-failure branch leaves a transaction-table slot occupied indefinitely — the eventual -190 shows up far from, and long after, the code that actually caused it.

Diagnostic Checks

1. Review current transaction table usage:

   onstat -x
   

2. Look specifically for long-running or seemingly orphaned transactions, not just the total count.
3. Check application code for transaction-leak patterns — missing commit/rollback on error exit paths.

Related Errors / Related Topics

• -134 — "ISAM error: no more locks." The closest sibling — the same "genuine capacity pressure vs. leaked/long-held resource" investigation applies, for locks rather than transaction-table slots.
• -141 — "ISAM error: tblspace table overflow." Another concurrency-driven capacity ceiling in the same general troubleshooting family.

Check onstat -x first, and look at how long transactions have been open, not just how many — that distinction determines whether this needs more capacity or a leak fix.