Informix Error -259

Reasons / Common Causes

-259 means a statement referenced a cursor that isn't open — and the official text calls out an easy-to-miss detail behind one of the most common causes: COMMIT WORK and ROLLBACK WORK close cursors automatically, unless the cursor was declared WITH HOLD.

1. FETCH/CLOSE (or similar) attempted before OPEN was ever called on the cursor — the direct, straightforward case.
2. A COMMIT WORK or ROLLBACK WORK executed mid-loop, between FETCH calls, unintentionally closing the cursor. This is a very common, easy-to-miss gotcha, especially in code that commits periodically inside a fetch loop for batching purposes — the cursor doesn't survive that commit unless it was declared to.
3. Assuming a cursor stays open across a transaction boundary without declaring it WITH HOLD.
4. An OPEN that failed silently — its return value wasn't checked, and subsequent code assumes the cursor is open when it isn't.

Solutions / Resolution

1. Review program logic for a missing OPEN before the cursor is used, per the official guidance.
2. If the code needs to commit or roll back while the cursor stays open across that boundary — a common pattern for batch processing inside a fetch loop — declare the cursor WITH HOLD explicitly.
3. Check the return value of OPEN to confirm it actually succeeded before proceeding to use the cursor.

Examples

COMMIT WORK closing a cursor mid-loop

DECLARE cur1 CURSOR FOR SELECT * FROM orders WHERE status = 'pending';
OPEN cur1;

WHILE (fetch_succeeds) DO
    FETCH cur1 INTO ...;
    process_row();
    IF (batch_size_reached) THEN
        COMMIT WORK;   -- closes cur1, since it wasn't declared WITH HOLD
    END IF;
END WHILE;
-- -259 on the next FETCH after the periodic COMMIT WORK

Fix — declare the cursor WITH HOLD so it survives the periodic commits:

DECLARE cur1 CURSOR WITH HOLD FOR SELECT * FROM orders WHERE status = 'pending';
OPEN cur1;

WHILE (fetch_succeeds) DO
    FETCH cur1 INTO ...;
    process_row();
    IF (batch_size_reached) THEN
        COMMIT WORK;   -- cur1 stays open
    END IF;
END WHILE;

An unchecked OPEN failure

isopen_result = EXEC SQL OPEN cur1;
/* return value not checked */
EXEC SQL FETCH cur1 INTO :rec;
/* -259 if the OPEN actually failed for an unrelated reason */

Diagnostic Checks

1. Review the call sequence for OPEN before the failing statement.
2. Check for a COMMIT WORK/ROLLBACK WORK between OPEN and the failing statement, and whether the cursor was declared WITH HOLD.
3. Check whether the original OPEN call's return value was verified.

Related Errors / Related Topics

• -207 — "Cannot update cursor declared on more than one table. / Cannot declare a SELECT INTO statement FOR UPDATE." Another cursor-declaration restriction in the same general family.
• -255 — "Not in transaction." Related through the same transaction-boundary-affects-cursor- state theme.

If this happens right after a periodic COMMIT WORK inside a fetch loop, declare the cursor WITH HOLD — that's almost always the fix.