Oninit
Talk to an expert →

Informix Error -265

-265 Load or insert cursors must be run within a transaction.

You attempted to open an insert cursor. This database has a transaction log. In such a database, you must execute a BEGIN WORK statement before you open a cursor that is declared with an INSERT statement or with the FOR UPDATE clause. Revise the logic of your program so that it starts a transaction before it opens the cursor.

You can ensure that the program also works in databases that do not have a transaction log. Change the program so that immediately after it executes the DATABASE statement, it saves the contents of the second element of the SQLAWARN array of warning flags in the SQL communications area. This element will contain a space if the database does not use transactions, and the letter W if it uses them. At each point where a transaction logically begins or ends, test the saved value. If it contains W, execute the transaction statement to begin or end a transaction.

Oninit® Troubleshooting Guidance

Reasons / Common Causes

-265 is a specific trigger within the broader transaction-lifecycle family: on a logged database, opening a cursor declared with INSERT or with the FOR UPDATE clause requires an active transaction — BEGIN WORK must run first.

  1. Opening an insert cursor or a FOR UPDATE cursor on a logged database without first executing BEGIN WORK — the direct cause.
  2. Portable embedded SQL code written to run against both logged and unlogged databases, without checking which mode actually applies, and so not conditionally issuing BEGIN WORK when it's needed.
  3. Confusion about scope — BEGIN WORK is required here specifically for insert-declared or FOR UPDATE cursors on a logged database, not universally for every operation.
Solutions / Resolution
  1. Revise program logic to execute BEGIN WORK before opening the cursor, per the official guidance.
  2. For portable code targeting both logged and unlogged databases, check the second element of the SQLAWARN array after executing the DATABASE statement to determine whether the database supports transactions, then conditionally execute BEGIN WORK based on that flag — this is the official, documented mechanism for handling both cases from one code path.
  3. Structure cursor-opening code to always begin a transaction first for insert/FOR UPDATE cursors, once the database is confirmed to be logged.
Examples
The direct fix
BEGIN WORK;
DECLARE cur1 CURSOR FOR INSERT INTO orders VALUES (?, ?, ?);
OPEN cur1;
Portable code checking SQLAWARN
EXEC SQL DATABASE mydb;
if (sqlca.sqlawarn.sqlawarn1 == 'W') {
    /* database supports transactions */
    EXEC SQL BEGIN WORK;
}
EXEC SQL DECLARE cur1 CURSOR FOR INSERT INTO orders VALUES (?, ?, ?);
EXEC SQL OPEN cur1;

This lets the same code run correctly against both logged and unlogged databases, issuing BEGIN WORK only when it's actually needed.

Diagnostic Checks
  1. Review the code path for BEGIN WORK before opening an insert or FOR UPDATE cursor.
  2. Check SQLAWARN's second element after DATABASE, if writing code intended to be portable across logged and unlogged databases.
Related Errors / Related Topics
  • -255 — "Not in transaction." Related through the same transaction-state-and-cursor interaction theme.
  • -122 — "ISAM error: transaction not available." The underlying logging-availability condition this error's requirement depends on.

For code that must work against both logged and unlogged databases, use the SQLAWARN-based conditional BEGIN WORK pattern rather than assuming one database mode.