Re: 4GL: SQLCA.SQLERRD[2] = 0 after insert in serial field
If you didn't touch is very extrange indeed. Maybe you have reached a maximun value for that column... but I'm only guessing... Chucho! Richard Spitz wrote: > Dear Informixers, > > I've been encountering a puzzling problem in a 4GL application. > 4GL version is 7.20UD1 (ancient I know, but we've been using this > version w/o any problems for years) running on Reliant Unix 5.43, > Server is IDS 7.31UD5 on Linux (SuSE 7.2). > > An INSERT statement inserts a record with a serial column. The > value of the serial is "0" before the insert, and the generated > serial value is retrieved with the following statement: > > LET p_stamm.s_doknr = SQLCA.SQLERRD[2] > > This has been working without any problems for years, and the > program code in this module has also not been changed. Sudden- > ly, this statement leaves "p_stamm.s_doknr" at value "0", > even though the insert was executed successfully. > > I'm aware there was a problem in previous versions of IDS 7.31 > that led to this problem, but this has been fixed and is > definitely not the case in 7.31UD5. > > I'm clueless about what's happening here. Could this be a > performance problem? I've been noticing that I have check- > point durations of 1 second lately, while they used to > be mostly 0 seconds. > > Does anybody here have a clue? > > Regards, Richard > -- Atte, Jesus Antonio Santos Giraldo ----------------------------------- jeansagi@myrealbox.com jeansagi@netscape.net sending to informix-list
Jean Sagi <jeansagi@myrealbox.com> schrieb: >Maybe you have reached a maximun value for that column... but I'm only >guessing... No, that is definitely not the case. The serial value is now in the 33000 range, and as I wrote, the insert and the creation of the serial value works ok. It was just the SQLCA.SQLERRD[2] that was suddenly not being set correctly any more. I reviewed the code and found that there was a "COMMIT WORK" statement between the INSERT statement and the readout of the SQLERRD[2] value. I was able to get rid of the explicit transaction so the readout comes directly after the INSERT, and now it works again. I'm just wondering why the error started to appear. There was definitely NO CHANGE in the module in question for almost two years, but the error just started to occur a few days ago. Regards, Richard -- +-------------------------------+-------------------------------+ | Dr. med Richard Spitz | Tel : +49-89-7095-6110 | | Klinik f'r Anaesthesiologie | FAX : +49-89-7095-6420 | | Klinikum der Univ. M'nchen | Page: +49-89-7095-789-2116 | | 81366 M'nchen, Germany | | +-------------------------------+-------------------------------+