Re: Errors 258 and 259

Steve Giles wrote: > We have a client who is getting sporatic -258 and -259 messages while > trying to insert a record. > A little background on the application; It is an OLTP environment that > passes through financial transactions. It is a 9.21.UC3 with AIX5.1 > environment. > > I understand that the errors have to do with cursors and the fact that > it cannot be found. What I'm not sure is why this is happening. Our > application declares and opens a cursor before every transaction (I > know it is not necessary to declare the cursor every transaction, but > I think that is another matter), and then closes it when it is done. > I've been talking to Informix and they say it must be a flaw in our > code (we use ESQL), but if it was a flaw I'm thinking that this would > be occuring more often (it has only happened twice in the past two > days). Also we have other client sites running the same code and this > has never happened. > > Does anyone have any thoughts as to what could be happening? You've received a couple of hints, but you didn't help us much because you've not said which language you are using. One effective way to get that behaviour is: file1.ec: void somefunc(void) { EXEC SQL OPEN c_mine; /* 1 */ ... another_func(); /* 2 */ ... EXEC SQL FETCH c_mine; /* 3 */ } file2.ec: void another_func(void) { EXEC SQL DECLARE c_mine CURSOR FOR SELECT ...; /* 4 */ EXEC SQL OPEN c_mine; /* 5 */ ... EXEC SQL CLOSE c_mine; /* 6 */ } Line 1 opens the cursor 'c_mine', line 2 calls a separate chunk of code that also happens to declare a cursor 'c_mine' (at 4) which effectively destroys the original c_mine. Line 5 opens the new variant of c_mine; line 6 closes it. When execution resumes at 3, the original c_mine has been destroyed and the new one is closed - that would lead to errors along the lines described. Note that if another_func() returned before closing its c_mine, then the original function would continue using the new (another_func) cursor - which could lead to interesting effects. In old code (and I mean really old code - like version 4.1x ESQL/C and earlier), cursor names were private to a source file. From 5.00 onwards, cursor names became global across all files in an application. (I4GL 6.00 and later tried to conceal this change from you, with varying degrees of success - B31661 is still seared into my brain; the current versions seems to have nailed the problem.) If you have recently migrated from really old ESQL/C to much newer ESQL/C, then this might be part of the issue. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

Jonathan Leffler <jleffler@earthlink.net> wrote in message news:<QuRxc.8591$uX2.4207@newsread2.news.pas.earthlink.net>... > Steve Giles wrote: > > We have a client who is getting sporatic -258 and -259 messages while > > trying to insert a record. > > A little background on the application; It is an OLTP environment that > > passes through financial transactions. It is a 9.21.UC3 with AIX5.1 > > environment. > > > > I understand that the errors have to do with cursors and the fact that > > it cannot be found. What I'm not sure is why this is happening. Our > > application declares and opens a cursor before every transaction (I > > know it is not necessary to declare the cursor every transaction, but > > I think that is another matter), and then closes it when it is done. > > I've been talking to Informix and they say it must be a flaw in our > > code (we use ESQL), but if it was a flaw I'm thinking that this would > > be occuring more often (it has only happened twice in the past two > > days). Also we have other client sites running the same code and this > > has never happened. > > > > Does anyone have any thoughts as to what could be happening? > > You've received a couple of hints, but you didn't help us much because > you've not said which language you are using. > > One effective way to get that behaviour is: > > file1.ec: > > void somefunc(void) > { > EXEC SQL OPEN c_mine; /* 1 */ > ... > another_func(); /* 2 */ > ... > EXEC SQL FETCH c_mine; /* 3 */ > } > > file2.ec: > > void another_func(void) > { > EXEC SQL DECLARE c_mine CURSOR FOR SELECT ...; /* 4 */ > EXEC SQL OPEN c_mine; /* 5 */ > ... > EXEC SQL CLOSE c_mine; /* 6 */ > } > > Line 1 opens the cursor 'c_mine', line 2 calls a separate chunk of > code that also happens to declare a cursor 'c_mine' (at 4) which > effectively destroys the original c_mine. Line 5 opens the new > variant of c_mine; line 6 closes it. When execution resumes at 3, the > original c_mine has been destroyed and the new one is closed - that > would lead to errors along the lines described. > > Note that if another_func() returned before closing its c_mine, then > the original function would continue using the new (another_func) > cursor - which could lead to interesting effects. > > In old code (and I mean really old code - like version 4.1x ESQL/C and > earlier), cursor names were private to a source file. From 5.00 > onwards, cursor names became global across all files in an > application. (I4GL 6.00 and later tried to conceal this change from > you, with varying degrees of success - B31661 is still seared into my > brain; the current versions seems to have nailed the problem.) > > If you have recently migrated from really old ESQL/C to much newer > ESQL/C, then this might be part of the issue. Oops, should have said ESQL/C (version 9.30UC1). The oldest version I can remember using is 7.23... I'm not even sure that this could be a code issue. Like I said we have the exact same code running in other places with the same version of Informix and we have never seen this problem before. This client seems to be the only one having any problems. They are also having other problems that they have not had since upgrading from SE. They weren't backing up the logical logs so last night we got a call because the application crashed (well duh!). They seem to blame the application for every error that happens. They also had a -404 error yesterday with an accompaning 25586. As far as I understand that would be some kind of notwork error? I'll keep digging in the code to see if there is something wacky going on. Thanks for all the ideas so far. Steve.