Informix Error -235

Reasons / Common Causes

-235 is a clear, specific type-size limit: CHAR columns can't exceed 32,767 characters, and VARCHAR columns can't exceed 255.

1. A CHAR column width specified greater than 32,767.
2. A VARCHAR column width specified greater than 255 — this is the far more commonly hit limit in practice, since 255 is a comparatively modest ceiling.
3. A typo in the width specification — an extra digit, such as VARCHAR(2550) intended as VARCHAR(255).
4. A schema ported from a system with more generous VARCHAR limits — many systems allow much larger VARCHAR sizes, and porting a schema directly without checking Informix's specific 255-character cap trips this.
5. A genuine need to store more than 255 characters in a single column, without realizing VARCHAR simply has no wider option — the fix is a different data type, not a larger VARCHAR, and which type is correct depends on how the column will actually be used (see Solutions below).

Solutions / Resolution

1. If this is a typo, correct the width specification.
2. If the column still needs to behave like an ordinary character column — indexed, compared, sorted, used in ORDER BY/GROUP BY — use LVARCHAR instead, which allows up to 32,739 bytes while keeping normal character-type semantics. This is usually the better fit than TEXT for anything in the "a few hundred to a few thousand characters, but still a real column" range — names, addresses, descriptions, JSON-ish blobs you still want to query directly.
3. If the content is genuinely unbounded, or won't be indexed/compared/sorted directly, use TEXT, which allows unlimited lengths but behaves like a simple large object — it can't be indexed, and comparisons/ORDER BY/GROUP BY against it are restricted, per the official guidance.
4. When porting schemas from other systems, check VARCHAR/CHAR limits against Informix's specific caps (32,767 for CHAR, 255 for VARCHAR) rather than assuming the same limits apply as the source system — a source system's generous VARCHAR often maps to LVARCHAR here, not TEXT.

Examples

The typo

CREATE TABLE notes (id INT, content VARCHAR(2550));
-- -235: an extra digit — VARCHAR max is 255

Fix:

CREATE TABLE notes (id INT, content VARCHAR(255));

A column that still needs to be indexed and queried normally

CREATE TABLE products (id INT, description VARCHAR(2000));
-- -235: VARCHAR can't hold this much

Fix — use LVARCHAR when the column still needs ordinary character-type behavior:

CREATE TABLE products (id INT, description LVARCHAR(2000));

-- LVARCHAR can still be indexed, compared, and sorted like a normal column:
CREATE INDEX products_desc_idx ON products (description);
SELECT * FROM products ORDER BY description;

The genuinely unbounded content need

CREATE TABLE documents (id INT, body VARCHAR(5000));
-- -235: VARCHAR can't hold this much

Fix — use TEXT for genuinely unbounded content that won't be indexed or sorted directly:

CREATE TABLE documents (id INT, body TEXT);

Diagnostic Checks

1. Review the exact column width specified against the applicable limit (32,767 for CHAR, 255 for VARCHAR).
2. Determine whether this is a typo or a genuine need for larger storage — if genuine, decide between LVARCHAR (still indexable/comparable, up to 32,739 bytes) and TEXT (unbounded, but large-object semantics) based on how the column will actually be used, rather than reaching for TEXT by default.

Related Errors / Related Topics

• -132 — "ISAM error: rowsize too big." A related row-level size limit — worth checking together, since switching to TEXT for a large column also affects overall row-size calculations differently than a wide CHAR/VARCHAR would.
• -200 — "Identifier is too long." Another "too big" limit in the same general category, though for identifiers rather than column widths.

If the content genuinely needs to be this large, the fix is LVARCHAR or TEXT — not a larger VARCHAR/CHAR, since those two have hard ceilings that can't be raised. Choose LVARCHAR when the column still needs to behave like an ordinary character column (indexed, compared, sorted); choose TEXT only when the content is genuinely unbounded or won't be queried that way.