Re: open cursor ==> error -255/0

If your database has transactions, you can only open a cursor for update inside a transaction. If you aren't in a transaction, you would get an error indicating 'not in transaction' -- -255 looks appropriate. The long explanation from finderr for error -255 isn't complete, I think! Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> }From: Jacob Salomon <jake@apparel.net> }Date: Thu, 23 Jan 1997 16:05:47 GMT }X-Informix-List-Id: <news.32937> } }I am testing a program modification in which I need to do work on every }row in the active set of a user query. The user has entered query data }in a 4GL form, and has been browsing Next/Previous so the primary-key }cursor has been quite active. Now the user presses a menu selection }called "mass-operate". My response is to close the PKey-cursor and }repoen it. Here is a code snippet: } }538 function mass_approve() # Approve all credit-held NSRs for all }orders }539 # in this query's active set. }540 # Uses cursors created in llh_a_construct() }541 }##################################################################### }542 whenever error continue # For debugging }543 }544 close pkey_curs # This was opened in llh_a_construct }545 open pkey_curs # reopen it for fresh business }546 while sqlca.sqlcode = 0 }547 fetch pkey_curs }548 into m_oordrh.ord_num # Just get the primary key value }549 open lh_cursor }550 using m_oordrh.ord_num }551 fetch lh_cursor # Fetch again, just to lock the }row }552 into m_oordrh.ord_num }553 call approve_nsrs(m_oordrh.ord_num) }554 close lh_cursor # release the locking cursor }555 end while } }IMO, this code looks quite innocent. The close (line 545) comes off }with no problem. The reopen of the pkey_curs cursor goes just fine and }I get real data in the variable when I fetch it. Now I try to open the }locking cursor using the value I just fetched. I get error -255. } }Now error -255 is quite absurd for me to get here. Observe: } }$ finderr 255 }[]-255 Not in transaction. }[]This COMMIT WORK or ROLLBACK WORK statement cannot }[]be executed because no BEGIN WORK was executed to start }[]a transaction. Since no transaction was started, there is no }[]need to end one. Any database modifications that were }[]done are now permanent; they cannot be rolled back but do }[]not need to be committed. Review the sequence of SQL }[]statements to see where the transaction should have started. } }This statement is basically correct; I was not running in a transaction. }However, as y'all can see, I also wasn't running a *&^^%! commit or }rollback to engender this kind error. } }It would appear that I simply got back the wrong error code. Otherwise, }something *has* gone awry in opening the locking cursor. OK, when I }created the cursor, what did it look like? } }225 let scratch # Locking cursor for the row }226 = "select ord_num from orders_tab", }227 " where ord_num = ?", }228 " for update" }229 prepare lh_stmt from scratch }230 declare lh_cursor cursor for lh_stmt } }So when opened and running (heh,heh) it will somply fetch that column }again and lock the row. At least that's the idea. } }Has anyone ever run across such an error opening a cursor? Any clue }what's causing it?