Informix Error -198

Reasons / Common Causes

-198 is another code that breaks the "ISAM error:" pattern — like -150, it's a different kind of message entirely, this time a well-documented, commonly-encountered practical limit on in-place ALTER TABLE operations. Informix's in-place alter mechanism is lazy: adding or altering a column doesn't immediately rewrite every row — rows convert to the new format as they're actually accessed or updated. Up to 255 such alters can be outstanding (not yet fully converted) per table at once; a 256th, requested before the first completes, hits this limit.

1. Frequent schema changes run in rapid succession against the same table, faster than the underlying rows are actually being touched to trigger their lazy conversion — each new in-place alter adds to the outstanding count rather than replacing a completed one.
2. A very large or infrequently-updated table where added columns via in-place alter never trigger full physical conversion, because rows simply aren't read or written often enough to complete it — successive ALTER TABLE statements keep stacking up outstanding alters until the limit is reached.
3. Automated migration tooling (ORM migrations, CI/CD schema-evolution frameworks) running many incremental ALTER TABLE statements against the same table without accounting for this limit or forcing completion between them.
4. Iterative schema design or testing — repeatedly adding and dropping columns against the same physical table without forcing completion in between each round.

Solutions / Resolution

The official guidance gives three explicit recovery options:

1. Wait for the first (and subsequent) alteration(s) to complete. If the table is actively read and written, in-place alters complete naturally as rows are touched — for a live, actively-used table, simply waiting may be enough.
2. Use a different ALTER TABLE format that doesn't add columns at the end of the table. This avoids triggering the specific in-place fast-path mechanism — understand that the alternate format may fall back to a full table rewrite instead, which is slower but doesn't accumulate against this particular limit.
3. Perform a dummy update on all rows to force completion of outstanding alterations — touching every row explicitly forces the lazy conversion machinery to complete the physical alter for all outstanding requests, freeing up the counter:

   UPDATE mytable SET somecol = somecol;
   

For recurring cases, consider structural fixes:

4. For migration tooling, add an explicit "force completion" step between successive ALTER TABLE operations on the same table — especially important for large or infrequently-touched tables where natural row access won't complete conversions promptly.
5. Batch multiple planned column changes into fewer ALTER TABLE statements where possible, rather than issuing many separate rapid alters against the same table.

Examples

Forcing completion with a dummy update

ALTER TABLE customer ADD COLUMN preferences VARCHAR(200);
-- outstanding in-place alter #1

-- Force it to complete before the next migration step:
UPDATE customer SET id = id;

ALTER TABLE customer ADD COLUMN last_login DATETIME YEAR TO SECOND;
-- now proceeds without contributing to a growing backlog

Migration tooling accumulating outstanding alters

A CI/CD pipeline runs a sequence of incremental schema migrations against a large, infrequently-queried archive table — each ALTER TABLE ADD COLUMN completes instantly from the DDL statement's own perspective, but the underlying rows are rarely touched, so none of the in-place conversions ever complete. After 255 such migrations accumulate, the 256th fails with -198 — the fix is adding a forced completion step (a dummy full-table update) into the migration pipeline itself.

Diagnostic Checks

1. Review recent ALTER TABLE history for the specific table, looking for many rapid, successive in-place alters.
2. Confirm whether the table is large or infrequently touched — this explains why lazy conversion hasn't completed on its own.
3. Check with administrative/check utilities for the version in use to see the table's current count of outstanding in-place alters, if such a check is available.

Related Errors / Related Topics

• -150 — "The limits of the IBM Informix Demo Version have been exceeded." The other code in this general numeric neighborhood that isn't an "ISAM error:" message.
• -132 — "ISAM error: rowsize too big." Another ALTER TABLE/column-definition constraint, though a hard structural limit rather than an in-progress-count ceiling.

If this recurs on the same table repeatedly, add a forced-completion step (a dummy full-table update) between schema changes rather than just waiting each time — that's the durable fix for migration tooling that touches the same table often.