Informix Error -227: DDL operations on ROWID prohibited.

Reasons / Common Causes

-227 is a clear, well-defined restriction: ROWID — the automatic, system-managed virtual column present on every non-fragmented table — can be selected and compared in a WHERE clause, but it can never be altered, renamed, or dropped through DDL.

1. Attempting ALTER TABLE to modify, rename, or drop the ROWID column — not permitted, since it's automatically managed by the engine rather than a genuine user-defined column.
2. Attempting CREATE TABLE with an explicit ROWID column definition that conflicts with the automatic one, or attempting to redefine its type or constraints.
3. Confusion about ROWID's nature. Since it can be selected and compared (unlike some of its other restrictions — see -205), it's reasonable, but incorrect, to assume it can also be altered like an ordinary column.
4. Generic schema-migration tooling iterating over "all columns" and mistakenly attempting to apply a DDL operation to ROWID along with genuine user-defined columns.
5. DDL ported from another system with different rules for a similar pseudo-column, not accounting for Informix's specific restriction here.

Solutions / Resolution

1. Don't attempt DDL against ROWID. There's no workaround — it's automatically managed and can't be altered, renamed, or dropped by any DDL statement.
2. For generic schema-migration tooling, exclude ROWID from any DDL operation that iterates over "all columns," since it isn't a genuine user-managed column.
3. Continue using ROWID normally in SELECT and WHERE clauses — only DDL modification is restricted, not read access.
4. When porting DDL from another system, remove any explicit ROWID column handling — Informix manages this automatically and doesn't need, or allow, explicit DDL control over it.

Examples

The disallowed operation

ALTER TABLE customer DROP COLUMN ROWID;
-- -227: ROWID can't be modified via DDL

Correct usage: reading, not altering

SELECT ROWID, name FROM customer WHERE ROWID = 12345;
-- perfectly valid — ROWID can be selected and compared freely

Generic tooling mistakenly targeting ROWID

-- A migration tool iterates over every column reported by the
-- catalog and attempts a type-check ALTER on each
for col in all_columns(table):
    alter_column_type(table, col, ...)
-- fails with -227 when it reaches ROWID

Excluding ROWID from the tool's column iteration resolves this.

Diagnostic Checks

1. Review the DDL statement to confirm ROWID is the column actually being targeted.
2. Check schema-migration tooling logic for whether it's iterating over "all columns" including ROWID without excluding it.

Related Errors / Related Topics

• -205 — "The statement failed because you cannot use ROWID for views with union, intersect, minus, aggregates, group by, multiple tables, or derived tables." Another ROWID restriction, though about which views support it rather than DDL modification.
• -126 — "ISAM error: bad row id." The other ROWID-related error in this catalogue, concerning stale or corrupted physical references rather than a DDL restriction.

Exclude ROWID from any generic "apply this DDL to every column" logic — it's the one column on a table that DDL simply can't touch.