Informix Error -132

Reasons / Common Causes

-132 means a table's row definition exceeds the engine's page-size limit — the official text is direct that the ceiling on a single row is simply the disk page size the database server supports. Every cause traces back to a table definition that, combined, is too wide for a page.

1. Too many columns, or columns wide enough, that the combined fixed-length row size exceeds the page size. Straightforward once identified, but easy to reach gradually.
2. Columns added incrementally over time via ALTER TABLE ADD COLUMN, with the cumulative row size crossing the limit without anyone tracking the running total as each column was added.
3. Generously oversized CHAR/VARCHAR declarations — VARCHAR(255) used defensively across many columns "just in case," inflating the row's maximum possible size even when actual data is usually far shorter. Depending on version, row-size limits are calculated against the declared maximum length, not the typical actual length.
4. A page size smaller than assumed for the specific dbspace or instance. Page size varies by platform and configuration (commonly 2KB, 4KB, or larger depending on setup) — a table definition that would fit comfortably on one configuration can exceed the limit on another.
5. A schema ported directly from a system with no equivalent page-size-bound row limit (or a much larger one), without adjusting the design for this specific constraint.
6. A denormalized "one big table" design collecting many logically distinct attributes into a single table rather than properly normalizing them into related tables.

Solutions / Resolution

1. Split the table into two or more related tables. Move less frequently accessed or logically separate columns into a companion table linked by a foreign key — the official guidance's own primary recommendation.
2. Adopt more compact data types. Use appropriately sized CHAR/VARCHAR lengths instead of defensively oversized ones, and prefer smaller numeric types where the actual value range allows it.
3. Move large or optional content into columns designed for it (BYTE/TEXT) rather than wide fixed-length columns, if not already doing so — large object columns are typically stored differently from the fixed portion of a row.
4. Check the specific dbspace/instance's configured page size before finalizing a wide table's design — if a larger page size is available and supported for a new dbspace, that provides more headroom, though page size is usually fixed at dbspace creation and not something to change after the fact.
5. Calculate the resulting row size before adding new columns to an already-wide table via ALTER TABLE, rather than discovering the limit only when the ALTER TABLE itself fails.
6. When porting a schema from another system, check this specific row-size limit early in the design or migration process rather than assuming direct compatibility.

Examples

The incremental growth that finally tips over

-- Table has grown column by column over several years
ALTER TABLE customer_profile ADD COLUMN preferences VARCHAR(500);
-- -132: this column's addition pushes the row past the page-size limit,
-- even though no single ALTER TABLE looked unreasonable in isolation

Nobody's individual change was wrong — the cumulative effect of many additions over time is what finally crossed the limit. Calculating the running total before each addition catches this before it becomes a failure at deployment time.

Oversized defensive VARCHAR declarations

CREATE TABLE wide_form
(
    field1  VARCHAR(255),
    field2  VARCHAR(255),
    field3  VARCHAR(255),
    -- ... 30 more VARCHAR(255) columns, most holding short values in practice
);
-- -132: the declared maximum lengths, summed, exceed the page size,
-- even though actual data rarely approaches 255 characters per field

Right-sizing the declared lengths to what the data actually needs (or genuinely could need) resolves this without changing the table's logical structure.

Splitting a wide table

-- Before: one table with 60 columns, exceeding the row-size limit
-- After: split by logical grouping
CREATE TABLE customer_core (customer_id INT, name VARCHAR(50), ...);
CREATE TABLE customer_preferences (customer_id INT, preferences VARCHAR(500), ...);
CREATE TABLE customer_billing (customer_id INT, billing_info VARCHAR(200), ...);

Splitting by how the data is actually accessed (frequently vs. rarely, logically related groups) usually produces a better design than an arbitrary split purely to satisfy the row-size limit.

Diagnostic Checks

1. Calculate the sum of column widths/max lengths for the failing table definition directly — this confirms the limit is actually the issue and shows by how much.
2. Check the dbspace's configured page size:

   onstat -d
   

3. Review ALTER TABLE history for the table in question, if the limit was crossed incrementally rather than in the original CREATE TABLE.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family.
• -114 — "ISAM error: the file name is too long." A different length limit entirely (a filename constraint versus a row-size constraint), but the same general troubleshooting posture: identify the specific limit, measure against it directly, and don't look for a workaround where none exists.

There's no override for this limit — the fix is always narrowing the row definition, whether through normalization, right-sizing data types, or moving large content into large-object columns.