Help Please - Bug 78956

A while ago I encountered a problem runing a reporting program which resulted in the following error in the IDS log : 12:16:08 Informix Dynamic Server Version 7.30.UC2 12:16:08 Who: Session(1298, pal5@pluto, 140, 0) Thread(1386, sqlexec, 0, 4) File: rsread.c Line: 2260 12:16:08 Results: Record not read 12:16:08 Action: Please notify Informix Technical Support. 12:16:22 See Also: /ascii/af.56ad907, shmem.56ad907.0 Also , the program output details to the standard error log : Program error at "agacprt.4gl", line number 588. SQL statement error number -243. Could not position within a table (pal5.t_aadistagt). SYSTEM error number -172. ISAM error: Unexpected internal error Following this I contacted Informix support who came up with : >Hi Robert, >It looks like your hitting bug 78956. This has been scheduled >to be fixed in 7.30.UC11 & 7.31.UC5. >From the bug description I suspect >that rebuilding the index should resolve the problem temporarily. >Regards, First of all t_aadistagt is a temporary table. So its created each and every run. I thought secondly that after this table is created some of its rows are deleted by processing , so the bad table must be the permanent one used in the join i.e DELETE FROM t_aadistagt WHERE ( (SELECT COUNT(*) FROM prbibcentre WHERE aad_dist = ibc_dist AND aad_agent = ibc_agent) = 0 ) AND ( aad_year = g_prev_year AND aad_period = g_prev_period ) So , I dropped the table prbibcentre and re-created it. Still the problem is not solved. My final thoughts are A) perhaps I'll make t_aadistagt a permanent table and just clear it out every run. B) Call Informix and see what they suggest. I should point out that the program works fine when the delete is not executed. Also , in the same program , a similar delete but for a different reason results in the program running very very slowly, almost hanging, but when that DELETE is omitted the program runs fine. Both DELETES and all the main processing is done on the TEMP table t_aadistagt. Hope someone out there can help........... thanks in advance. Even if perhaps explain exactly what this bug is and what its doing ? PS - Its not beyond the realms of possibility that its my code ! : )

Do you have a case number??? Normally this bug will only occur if multiple programs are hitting the same indexes. However, I suspect that it might be able to reproduce if either LRU MIN/MAX is set to zero and/or the table is not logged. Robert Taylor wrote: > A while ago I encountered a problem runing a reporting program which > resulted in the following error in the IDS log : > > 12:16:08 Informix Dynamic Server Version 7.30.UC2 > 12:16:08 Who: Session(1298, pal5@pluto, 140, 0) > Thread(1386, sqlexec, 0, 4) > File: rsread.c Line: 2260 > 12:16:08 Results: Record not read > 12:16:08 Action: Please notify Informix Technical Support. > 12:16:22 See Also: /ascii/af.56ad907, shmem.56ad907.0> > Also , the program output details to the standard error log : > > Program error at "agacprt.4gl", line number 588. > SQL statement error number -243. > Could not position within a table (pal5.t_aadistagt). > SYSTEM error number -172. > ISAM error: Unexpected internal error> > Following this I contacted Informix support who came up with : > >Hi Robert, > > >It looks like your hitting bug 78956. This has been scheduled > >to be fixed in 7.30.UC11 & 7.31.UC5. > >From the bug description I suspect > >that rebuilding the index should resolve the problem temporarily. > >Regards, > > First of all t_aadistagt is a temporary table. So its created each and every > run. > I thought secondly that after this table is created some of its rows are > deleted by processing > , so the bad table must be the permanent one used in the join i.e > > DELETE FROM t_aadistagt > WHERE > ( (SELECT COUNT(*) FROM prbibcentre > WHERE aad_dist = ibc_dist AND aad_agent = ibc_agent) > = 0 ) > AND > ( aad_year = g_prev_year AND aad_period = g_prev_period )> > So , I dropped the table prbibcentre and re-created it. Still the problem is > not solved. > > My final thoughts are > A) perhaps I'll make t_aadistagt a permanent table and just clear it out > every run. > B) Call Informix and see what they suggest. > > I should point out that the program works fine when the delete is not > executed. > Also , in the same program , a similar delete but for a different reason > results in the program running very very slowly, almost hanging, but when > that DELETE is omitted the program runs fine. > Both DELETES and all the main processing is done on the TEMP table > t_aadistagt. > > Hope someone out there can help........... thanks in advance. Even if > perhaps explain exactly what this bug is and what its doing ? > > PS - Its not beyond the realms of possibility that its my code ! : )

Madison Pruet wrote in message <3875F088.987F611B@informix.com>... >Do you have a case number??? > >Normally this bug will only occur if multiple programs are hitting the same >indexes. However, I suspect that it might be able to reproduce if either LRU >MIN/MAX is set to zero and/or the table is not logged. > I am ther dba at SLL and work with robert. Its case no 911-593 and I have contacted Adam Hattrell (adamh@informix.com) again saying we are still having problems. I have LRU_MAXDIRTY = 2 and LRU_MIN_DIRTY=1. We have buffered logging on the database but I do not know is there is logging on the temp table. >Robert Taylor wrote: > >> A while ago I encountered a problem runing a reporting program which >> resulted in the following error in the IDS log : >> >> 12:16:08 Informix Dynamic Server Version 7.30.UC2 >> 12:16:08 Who: Session(1298, pal5@pluto, 140, 0) >> Thread(1386, sqlexec, 0, 4) >> File: rsread.c Line: 2260 >> 12:16:08 Results: Record not read >> 12:16:08 Action: Please notify Informix Technical Support. >> 12:16:22 See Also: /ascii/af.56ad907, shmem.56ad907.0>> >> Also , the program output details to the standard error log : >> >> Program error at "agacprt.4gl", line number 588. >> SQL statement error number -243. >> Could not position within a table (pal5.t_aadistagt). >> SYSTEM error number -172. >> ISAM error: Unexpected internal error>> >> Following this I contacted Informix support who came up with : >> >Hi Robert, >> >> >It looks like your hitting bug 78956. This has been scheduled >> >to be fixed in 7.30.UC11 & 7.31.UC5. >> >From the bug description I suspect >> >that rebuilding the index should resolve the problem temporarily. >> >Regards, >> >> First of all t_aadistagt is a temporary table. So its created each and every >> run. >> I thought secondly that after this table is created some of its rows are >> deleted by processing >> , so the bad table must be the permanent one used in the join i.e >> >> DELETE FROM t_aadistagt >> WHERE >> ( (SELECT COUNT(*) FROM prbibcentre >> WHERE aad_dist = ibc_dist AND aad_agent = ibc_agent) >> = 0 ) >> AND >> ( aad_year = g_prev_year AND aad_period = g_prev_period )>> >> So , I dropped the table prbibcentre and re-created it. Still the problem is >> not solved. >> >> My final thoughts are >> A) perhaps I'll make t_aadistagt a permanent table and just clear it out >> every run. >> B) Call Informix and see what they suggest. >> >> I should point out that the program works fine when the delete is not >> executed. >> Also , in the same program , a similar delete but for a different reason >> results in the program running very very slowly, almost hanging, but when >> that DELETE is omitted the program runs fine. >> Both DELETES and all the main processing is done on the TEMP table >> t_aadistagt. >> >> Hope someone out there can help........... thanks in advance. Even if >> perhaps explain exactly what this bug is and what its doing ? >> >> PS - Its not beyond the realms of possibility that its my code ! : ) > > > >

Case : RE: 911-593 , Scottish Legal Life The table is temporary and therefore is created via SELECT ....WITH NO LOG.

Removing WITH NO LOG has corrected my problem. I guess the DELETE of rows from the temporary table was causing problems with no logging on the table. I should be able to use WITH NO LOG ( and it's probably better when I don't care about the table data etc ) shouldn't I ? My problem is now sorted though so thats me happy........

I'm glad to hear that it seems to be resolving the problem. Yes - you should be able to use *WITH NO LOG*. As you were aware, you ran into a bug. The workarround tends to avoid the problem. Robert Taylor wrote: > Removing WITH NO LOG has corrected my problem. I guess the DELETE of rows > from the temporary table was causing problems with no logging on the table. > I should be able to use WITH NO LOG ( and it's probably better when I don't > care about the table data etc ) shouldn't I ? > > My problem is now sorted though so thats me happy........