Oninit
Talk to an expert →

Informix Error -257

-257 System limit on maximum number of statements exceeded, maximum is

count.

The database server can handle only a fixed number of prepared SQL statements for each user. This limit includes statements that were prepared with the PREPARE statement and cursors that were declared with the DECLARE statement. This statement (PREPARE, DECLARE, or PREPARE IMMEDIATE) exceeds that limit and is not executed. The FREE statement releases prepared statements. Review the logic of your program, and change it so that it frees prepared statements when it no longer needs them.

Version 5.0 and later database servers do not have this restriction. However, programs that must be compatible with earlier versions should use FREE to stay under the limit.

Oninit® Troubleshooting Guidance

Reasons / Common Causes

-257 is a resource-management condition on pre-5.0 database servers: only a fixed number of prepared statements (from PREPARE) and declared cursors (from DECLARE) can exist per user at once, and this limit was reached. The official text notes Version 5.0 and later don't have this restriction at all — but programs needing compatibility with earlier versions still need to manage it.

  1. Too many PREPARE/DECLARE statements accumulated for one user without corresponding FREE calls — a resource leak in program logic, not a hard data limit.
  2. A program preparing statements in a loop — dynamically building and preparing a new statement each iteration — without freeing previous ones first.
  3. Long-running processes or sessions accumulating prepared statements over their lifetime without periodic cleanup.
  4. Compatibility code targeting pre-5.0 servers not managing the prepared-statement lifecycle via FREE, relying on an assumption (true only on 5.0+) that this limit doesn't apply.
Solutions / Resolution
  1. Use the FREE statement to release prepared statements and cursors once no longer needed, per the official guidance.
  2. Review program logic for the prepare/declare lifecycle and add explicit FREE calls at appropriate points — especially inside loops or long-running sessions.
  3. On Version 5.0+, this restriction doesn't apply, but for compatibility with earlier versions, continue using FREE to stay under the limit regardless.
  4. For long-running processes, periodically audit and free statements that are no longer actively in use.
Examples
The leak: preparing in a loop without freeing
for (i = 0; i < num_queries; i++) {
    sprintf(stmt_text, "SELECT * FROM table_%d", i);
    EXEC SQL PREPARE stmt FROM :stmt_text;
    EXEC SQL EXECUTE stmt;
    /* stmt never freed — accumulates one more prepared statement
       against the limit on every iteration */
}

Fix:

for (i = 0; i < num_queries; i++) {
    sprintf(stmt_text, "SELECT * FROM table_%d", i);
    EXEC SQL PREPARE stmt FROM :stmt_text;
    EXEC SQL EXECUTE stmt;
    EXEC SQL FREE stmt;
}
Diagnostic Checks
  1. Review program logic for PREPARE/DECLARE calls without corresponding FREE calls.
  2. Check the actual server version — Version 5.0 and later don't enforce this limit at all, so confirm the restriction is genuinely relevant before investing effort in a fix aimed at compatibility with older versions.
Related Errors / Related Topics
  • -134 — "ISAM error: no more locks." A different resource-ceiling condition, but sharing the same "leak vs. genuine capacity need" diagnostic pattern.
  • -190 — "ISAM error: Transaction table overflow." Another resource-table exhaustion condition in the same general family.

Check the actual server version first — this restriction doesn't exist at all on Version 5.0 and later, so confirm it's relevant before investing in a FREE-based fix aimed at older-version compatibility.