open cursor ==> error -255/0

Hi all, 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? Thanks. -- -- Jake Salomon . . _..-'( )`-.._ ./'. '||\\\\. }\\_/{ .//||` .`\\. ./'.|'.'||||\\\\|.. )o o( ..|//||||`.`|.`\\. ./'..|'.|| |||||\\`````` \\'@'/ ''''''/||||| ||.`|..`\\. ./'.||'.|||| ||||||||||||. | .|||||||||||| ||||.`||.`\\. /'|||'.|||||| ||||||||||||{ | }|||||||||||| ||||||.`|||`\\ '.|||'.||||||| ||||||||||||{ | }|||||||||||| |||||||.`|||.` '.||| ||||||||| |/' ``\\||`` | ''||/'' `\\| ||||||||| |||.` |/' \\./' `\\./ \\!|\\ /|!/ \\./' `\\./ `\\| V V V }' `\\ /' `{ V V V \\ \\ \\ V / / / +-----------------------------------------------------------+ | Impeccable Logic: A thought process which successfully | | resists chicken bites | +-----------------------------------------------------------+