Oninit
Talk to an expert →

Informix Error -232

-232 A SERIAL column column-name may not be updated.

You cannot alter the contents of a column with the SERIAL or SERIAL8 or BIGSERIAL data type in the UPDATE statement, even when the updating value is zero. (You can specify a value of zero for a serial column when you use the INSERT statement; the database server ignores the zero and inserts a generated number.) Revise the statement so that only nonserial columns are updated.

Oninit® Troubleshooting Guidance

Reasons / Common Causes

-232 is a categorical restriction: a SERIAL/SERIAL8/BIGSERIAL column's value can never be changed via UPDATE, even to zero. This is worth contrasting directly with INSERT behavior, where zero is a special placeholder the engine recognizes and replaces with a generated value — UPDATE has no equivalent special-casing at all, so any attempt to touch a serial column fails.

  1. Attempting to UPDATE a serial column's value directly — not permitted under any circumstances, including setting it to zero.
  2. Confusion about INSERT-time zero behavior carrying over to UPDATE. It doesn't — zero as an INSERT value is a recognized placeholder that triggers auto-generation; UPDATE simply disallows touching the column at all, with no special value that's treated differently.
  3. Generic ORM or "save" logic that issues an UPDATE with every column — including the serial primary key — in the SET list, unintentionally including it.
  4. A migration or data-correction script attempting to explicitly renumber or reassign serial values via UPDATE, not realizing this is categorically disallowed.
Solutions / Resolution
  1. Revise the statement so only nonserial columns are updated, per the official guidance — remove the serial column from the SET clause entirely.
  2. For generic ORM or "save" logic, exclude the serial primary key from any UPDATE statement's SET list — it should only ever appear in the WHERE clause identifying which row to update.
  3. If a serial column's value genuinely needs to change (a rare, unusual need), that requires a different approach entirely — recreating the row with a new value via delete-and-insert, or, for sequence realignment after a bulk load, the ALTER TABLE MODIFY approach covered under -100's guidance for SERIAL collisions — not a direct UPDATE.
Examples
The disallowed update
UPDATE customer SET customer_id = 0, name = 'Jane Doe' WHERE customer_id = 42;
-- -232: customer_id is SERIAL and can't be touched by UPDATE,
-- even with a value of zero

Fix — update only the nonserial columns:

UPDATE customer SET name = 'Jane Doe' WHERE customer_id = 42;
An ORM's generic save() including the primary key
-- Generic save logic building an UPDATE from every mapped field,
-- including the serial primary key
UPDATE orders SET order_id = :id, status = :status, total = :total
WHERE order_id = :id;
-- -232: order_id shouldn't be in the SET list at all

Excluding the primary key from the SET clause — using it only in WHERE — resolves this.

Diagnostic Checks
  1. Review the UPDATE statement's SET clause for a SERIAL/SERIAL8/BIGSERIAL column.
  2. Review ORM or generic update logic for whether it correctly excludes serial/auto-increment columns from UPDATE operations, including it only in WHERE.
Related Errors / Related Topics
  • -100 — "ISAM error: duplicate value for a record with unique key." Covers SERIAL collision scenarios and the ALTER TABLE MODIFY approach for realigning a sequence — the relevant alternative when a serial value genuinely needs adjustment.
  • -201 — "A syntax error has occurred." The general SQL-parsing-error family this fits into.

Never include a serial column in an UPDATE statement's SET clause — use it only in WHERE to identify the row.