Oninit
Talk to an expert →

Informix Error -400

-400 Fetch attempted on unopen cursor.

This FETCH statement names a cursor that has never been opened or has been closed. Review the program logic, and check that it will open the cursor before this point and not accidentally close it. Unless a cursor is declared WITH HOLD, it is automatically closed by a COMMIT WORK or ROLLBACK WORK statement.

Oninit® Troubleshooting Guidance

Reasons / Common Causes

-400 is a program-logic sequencing error: FETCH was issued against a cursor that was never opened, or that was opened but has since been closed — including implicitly closed by transaction completion.

  1. A FETCH issued before the corresponding OPEN cursor statement — a straightforward ordering mistake.
  2. A FETCH issued after CLOSE on the same cursor, without reopening it.
  3. A COMMIT WORK/ROLLBACK WORK implicitly closing the cursor, since cursors close automatically at transaction end unless declared WITH HOLD — a FETCH after that point fails even though the code never explicitly closed anything.
  4. Application error-handling logic that retries a FETCH loop after a transaction boundary without checking whether the cursor needs to be reopened.
Solutions / Resolution
  1. Review program logic to ensure the cursor is opened before every FETCH, per the official guidance.
  2. If the cursor needs to survive across COMMIT WORK/ROLLBACK WORK, declare it WITH HOLD at declaration time, rather than assuming it stays open by default.
  3. In loops spanning transaction boundaries, explicitly reopen the cursor after each commit if WITH HOLD isn't used.
Examples
Fetching before opening
DECLARE curs1 CURSOR FOR SELECT * FROM orders;
FETCH curs1;
-- -400: curs1 was never opened

Fix:

DECLARE curs1 CURSOR FOR SELECT * FROM orders;
OPEN curs1;
FETCH curs1;
Declaring WITH HOLD to survive a transaction boundary
DECLARE curs1 CURSOR WITH HOLD FOR SELECT * FROM orders;
OPEN curs1;
FETCH curs1;
COMMIT WORK;
FETCH curs1;
-- succeeds: WITH HOLD keeps curs1 open across the commit
Diagnostic Checks
  1. Confirm the cursor was opened before the failing FETCH.
  2. Check for an intervening CLOSE, COMMIT WORK, or ROLLBACK WORK between the OPEN and the failing FETCH.
  3. Check whether the cursor was declared WITH HOLD, if it's expected to survive a transaction boundary.
Related Errors / Related Topics
  • -401 — "Fetch attempted on NULL cursor." A related, more severe cursor-state error (invalid/corrupted cursor data structure), largely superseded by -267/-404 on version 5.0 and later servers.
  • -363 — "CURSOR not on SELECT statement." Another cursor-declaration-level restriction, though about the underlying statement type rather than open/close state.

Cursors close automatically at COMMIT WORK/ROLLBACK WORK unless declared WITH HOLD — that's the most commonly overlooked cause of a FETCH failing on a cursor the code never explicitly closed.