Informix Error -255

Reasons / Common Causes

-255 is the SQL-level counterpart to -124's ISAM-level "no begin work yet" — but it carries an important, distinct operational consequence worth understanding immediately, not just the same sequencing bug.

1. A COMMIT WORK or ROLLBACK WORK issued without a preceding BEGIN WORK — the same core condition as -124.
2. Opening a cursor FOR UPDATE without having started a transaction first. The official text specifically names this as a distinct trigger path, separate from an explicit COMMIT/ROLLBACK mistake.
3. The same underlying sequencing bugs -124 already covers — double-commit bugs, unconditional cleanup rollbacks, connection-pooling state confusion.

Solutions / Resolution

1. Understand immediately: any modifications already made are now permanent. The official text is explicit — they cannot be rolled back, and they don't need to be committed either. Issuing ROLLBACK WORK here won't undo anything; it will just fail with this same error, and the changes already made are stuck as they are. If those changes need to be undone, that requires a manual compensating action, not a rollback.
2. Review the sequence of SQL statements to identify where the transaction should have started, and add BEGIN WORK at the correct point.
3. For cursor FOR UPDATE usage, ensure a transaction has been explicitly started before opening the cursor.
4. Follow -124's guidance for the underlying sequencing bug — pairing every COMMIT/ROLLBACK with a preceding BEGIN WORK, guarding unconditional cleanup rollbacks, and reviewing connection-pooling transaction-state handling.

Examples

The critical data-safety implication

UPDATE orders SET status = 'shipped' WHERE order_id = 1001;
-- no BEGIN WORK ran before this — the UPDATE is already permanent

ROLLBACK WORK;
-- -255: there's no transaction to roll back, AND the UPDATE above
-- is not undone by this failure — it already happened

If undoing that UPDATE is actually necessary, it requires an explicit compensating statement (UPDATE orders SET status = 'pending' WHERE order_id = 1001;), not a rollback that can't apply retroactively to work that was never inside a transaction.

Cursor FOR UPDATE without a transaction

DECLARE cur1 CURSOR FOR
  SELECT * FROM orders WHERE status = 'pending' FOR UPDATE;
OPEN cur1;
FETCH cur1 INTO :rec;
UPDATE orders SET status = 'processing' WHERE CURRENT OF cur1;
COMMIT WORK;
-- -255: no BEGIN WORK preceded this sequence

Fix — start the transaction before opening the cursor:

BEGIN WORK;
DECLARE cur1 CURSOR FOR
  SELECT * FROM orders WHERE status = 'pending' FOR UPDATE;
OPEN cur1;
FETCH cur1 INTO :rec;
UPDATE orders SET status = 'processing' WHERE CURRENT OF cur1;
COMMIT WORK;

Diagnostic Checks

1. Review the call sequence for a missing BEGIN WORK before the failing COMMIT/ROLLBACK.
2. Check whether a cursor FOR UPDATE was opened without a preceding transaction start.
3. Assess whether the already-made modifications need a manual compensating correction — since automatic rollback isn't possible once this error has occurred.

Related Errors / Related Topics

• -124 — "ISAM error: no begin work yet." The ISAM-level counterpart to this same sequencing condition — see it for the fuller range of underlying bug patterns.
• -237 — "Cannot begin work." A different transaction-lifecycle failure — this one is about BEGIN WORK itself failing (usually a log-access problem), not about a missing BEGIN WORK.

Remember: this error means modifications already made cannot be rolled back — check immediately whether that's a problem requiring a manual fix, rather than assuming the failed ROLLBACK undid anything.