Error -256

Hi, I'm seeing error -256 when monitoring (onstat -g sql) an application running Online v 7.30. I know the error means that the program is trying to start a transaction when there is no logging. The problem is that the application is being converted from Informix Standard Engine and the code never used transaction logging and still doesn't. As a matter of fact, the same code is still running on SA with no ill effects. My question is twofold: 1. How do I find the errant code? Onstat -g sql only gives the last parsed SQL statement, not the program running. and 2. Is it serious? We are planning to turn on transaction logging soon and my understanding is that if a program starts a transaction with BEGIN and never issues a COMMIT the updates will be rolled back at the end of the program. Thanks, any advise will be appreciated. Ray Pastore Sent via Deja.com http://www.deja.com/ Before you buy.

r_pastore@my-deja.com wrote: > > Hi, > I'm seeing error -256 when monitoring (onstat -g sql) an > application running Online v 7.30. I know the error means that the > program is trying to start a transaction when there is no logging. The > problem is that the application is being converted from Informix > Standard Engine and the code never used transaction logging and still > doesn't. As a matter of fact, the same code is still running on SA with > no ill effects. > My question is twofold: > 1. How do I find the errant code? Onstat -g sql only gives the last > parsed SQL statement, not the program running. But onstat -g sql will give you the session id. The run onstat -g ses <sid> and the pid of the process will be included in that report. > and > 2. Is it serious? We are planning to turn on transaction logging soon > and my understanding is that if a program starts a transaction with > BEGIN and never issues a COMMIT the updates will be rolled back at the > end of the program. You should start every application with a detection of the logging status of the database so the app is independent of logging. Using the sqlca structure immediately after the connect or database statement check the sqlca.sqlwarn structure and set two global vis: commit_ok = (sqlca.sqlwarn.sqlwarn1 == 'W'); begins_ok = (commit_ok && sqlca.sqlwarn.sqlwarn2 != 'W'); The commit_ok will be true for any database with logging and begins_ok will be true for any NON-ANSI mode database with logging (you cannot issue a BEGIN WORK in an ANSI mode database). Now at the beginning of each unit of work add: if (begins_ok) EXEC SQL BEGIN WORK; and at the end (assume errcode indicates an application error requiring a rollback: if (commit_ok) if (!errcode) EXEC SQL COMMIT WORK; else EXEC SQL ROLLBACK WORK; Note also that some things are different once you turn on logging. For example if you LOCK TABLE you must do so AFTER a BEGIN WORK statement (in a non-ANSI mode database) and you CANNOT issue an UNLOCK TABLE at all the table will unlock automatically when you either COMMIT WORK or ROLLBACK WORK so you would protect the UNLOCK TABLE with 'if (!commit_ok)'. Also SET LOCK MODE TO WAIT <nsecs> is neccessary far more often with logging than without it because of the change in the default isolation level. Most of the issues are similarly minor. Art S. Kagel

In article <388C898D.35337451@bloomberg.net>, kagel@bloomberg.net wrote: > r_pastore@my-deja.com wrote: > > > > Hi, > > I'm seeing error -256 when monitoring (onstat -g sql) an > But onstat -g sql will give you the session id. The run onstat -g ses <sid> > and the pid of the process will be included in that report. Thanks, now I know the code to look at. > Note also that some things are different once you turn on logging. For > example if you LOCK TABLE you must do so AFTER a BEGIN WORK statement (in a > non-ANSI mode database) and you CANNOT issue an UNLOCK TABLE at all the table > will unlock automatically when you either COMMIT WORK or ROLLBACK WORK so you > would protect the UNLOCK TABLE with 'if (!commit_ok)'. Also SET LOCK MODE > TO WAIT <nsecs> is neccessary far more often with logging than without it > because of the change in the default isolation level. Most of the issues > are similarly minor. > > Art S. Kagel We hadn't thought of that, thanks. We did discover that we have modify cursor declaration to specify WITH HOLD as well as changing LOAD statements to DBLOAD so we could specify the number of inserts before commits. I'll let you know what I find when I look at the code. Ray Sent via Deja.com http://www.deja.com/ Before you buy.