Informix Error -528: Maximum output rowsize max-size exceeded.
Cause and resolution
Maximum output rowsize max-size exceeded.
The total number of bytes that this statement selects exceeds the maximum that can be passed between the database server and the program. Make sure that the columns selected are the ones that you intended. Check that you have not named some very wide character column by mistake, neglected to specify a substring, or specified too long a substring. If the selection is what you require, rewrite this SELECT statement into two or more statements, each of which selects only some of the fields. If it is a join of several tables, you might best select all desired data INTO TEMP; then select individual columns of the temporary table. If this is a fetch via a cursor in a program, you might revise the program as follows. First, change the cursor to select only the ROWID of the desired row. Second, augment the FETCH statement with a series of SELECT statements, each of which selects one or a few columns WHERE ROWID = the saved row ID.
Oninit® Troubleshooting Guidance
Reasons / Common Causes
-528 is a hard limit on how many bytes a single row of SELECT output can carry between the server and the client — a SELECT (or FETCH) whose selected columns sum past that limit is rejected outright, regardless of how much actual data any given row contains.
- A wide-column mistake in the SELECT list — per the official guidance, naming a very wide character column by accident, or forgetting to substring it.
- A join across several wide tables selected in full, where the combined row width of all joined columns exceeds the limit even though no single table's row would.
- A cursor FETCH into a program selecting far more columns per row than the program actually consumes, needlessly pushing the row width toward the limit.
Solutions / Resolution
- Confirm the selected columns are actually the ones intended, per the official guidance — check for an accidentally-included wide character column, a missing substring, or a substring specified too long.
- If the wide selection is genuinely required, split it into two or more statements, per the official guidance, each selecting only some of the fields.
- For a join, select everything
INTO TEMPfirst, then query individual columns from the temp table, per the official guidance, rather than trying to return the full wide join directly. - For a cursor-based FETCH in a program, per the official guidance's suggested rewrite:
first change the cursor to select only
ROWID, then follow the FETCH with a series ofSELECT ... WHERE ROWID = <saved id>statements, each selecting just the columns actually needed at that point.
Examples
Splitting a too-wide SELECT
-- Instead of one SELECT pulling every wide column from a join:
SELECT * FROM orders o, customers c, order_notes n
WHERE o.customer_id = c.customer_id AND o.order_id = n.order_id;
-- -528: combined row width exceeds the limit
-- Select into a temp table first, then query what's actually needed:
SELECT o.*, c.*, n.* FROM orders o, customers c, order_notes n
WHERE o.customer_id = c.customer_id AND o.order_id = n.order_id
INTO TEMP wide_join;
SELECT order_id, status FROM wide_join;
The ROWID-based cursor rewrite
DECLARE order_cursor CURSOR FOR SELECT ROWID rid FROM orders;
OPEN order_cursor;
FETCH order_cursor INTO :saved_rid;
SELECT status, ship_date FROM orders WHERE ROWID = :saved_rid;
Diagnostic Checks
- Review the SELECT list for unintentionally wide columns, especially
CHAR/VARCHAR/LVARCHARcolumns pulled in full where a substring would do. - Sum the declared widths of the selected columns across all joined tables if the query is a multi-table join, to see how close it runs to the limit.
Related Errors / Related Topics
No closely related error codes are cross-referenced for -528 in this set yet.
A row-width ceiling on SELECT output — narrow the column list, stage a wide join through a temp table, or switch a cursor to a ROWID-based two-step fetch.