Re: SQLCA.SQLCODE = NOTFOUND, STATUS = 0 ?

I feel fairly sure that this is bug B31948 or its DUP bug B36032. B31948 - 6.00.UE1 I4GL FETCH OF A DECIMAL TYPE RETURNS STATUS = O WHEN NO ROW IS FOUND B36032 - 4.12.UE1 I4GL SELECT STATEMENT RETURNS STATUS = 0 WHEN NO ROW IS FOUND. These bugs are fixed in versions 4.13.UD1 and 6.01.UD1, so the obvious solution is to upgrade. This was the subject of discussion a while ago (around Christmas?) in c.d.i, and I posted a modification to the c4gl script which allows you to work around the problem. This should be available from the c.d.i archives. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> }Date: Sun, 9 Jul 95 10:21:30 GMT }From: Bashir Akram <bash@bash.demon.co.uk> }To: johnl@informix.com }Subject: Re: SQLCA.SQLCODE = NOTFOUND, STATUS = 0 ? } }Hi Jonathan, } }There is a very good chance that one of the fields is decimal }I`ll check on Monday, let you know } }Looks like you have hit the nail on the head. } }Thanks. } }> Which of those fields is a decimal? }> }> I expect it is a side effect of the bug where decimals are checked }> and status is set 0 incorrectly... }> }> This is fixed in 4.14 for sure, and I think in 4.13. 4.14 is not yet }> generally available. }> }> Of course, if none of those fields are decimals, I'm barking up the }> wrong tree and you should ignore me (this time). }> }> Yours, }> Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> }From: Jim Gordon <jgordon@us.DHL.COM> }Date: Fri, 7 Jul 1995 17:20:23 -0700 }X-Informix-List-Id: <list.6846> } }On Jul 7, 11:03pm, Bashir Akram wrote: }> Subject: SQLCA.SQLCODE = NOTFOUND, STATUS = 0 ? }> One of our programs is doing a fetch (the select below), }> sqlca.sqlcode = NOTFOUND but STATUS = 0, so rather }> than checking on STATUS we have to check on sqlca.sqlcode. }> This is very strange? Anybody ever seen this before? }> It seems that this problem(?) applies to a few more selects in }> our product, looks like its safer to use sqlca.sqlcode? }> }> Informix say this is a known bug on early versions, how early }> is 4.12 on an IBM in the UK? }>-- End of excerpt from Bashir Akram } }4.12 is not exactly early but there is another possible reason that you are }seeing this problem. This is basic to 4GL so if this wasn't raised by your }support contact complain to his manager. } }sqlca.sqlcode records the status from the last SQL statement executed. }status records the status from the last statement executed. } }The result is that if you have the following } }select .... }let a = b } }at this point } status will = 0 } sqlca.sqlcode will = notfound } }For this reason if you want to trap SQL errors you should always use }sqlca.sqlcode not status as it is too easy for programmers to slip in a line by }mistake. } }Of course they may have re-introduced the bug but if this is only happening in }some places I would check your code first. } }Cheers - Jim }From: Sally Woolrich <Sally@excelsis.demon.co.uk> }Date: Mon, 10 Jul 95 12:37:13 GMT }X-Informix-List-Id: <news.15287> } }In article <3tkl6t$rtr@cssun.mathcs.emory.edu> } jgordon@us.DHL.COM "Jim Gordon" writes: } }> On Jul 7, 11:03pm, Bashir Akram wrote: }> > Subject: SQLCA.SQLCODE = NOTFOUND, STATUS = 0 ? }> > One of our programs is doing a fetch (the select below), }> > sqlca.sqlcode = NOTFOUND but STATUS = 0, so rather }> > than checking on STATUS we have to check on sqlca.sqlcode. }> <snip> }> }> sqlca.sqlcode records the status from the last SQL statement executed. }> status records the status from the last statement executed. } }Therefore at our site we always (one hopes!) use the following: } } some-SQL-statement } LET rtcd = STATUS } CASE ( rtcd ) } .... } }Non-SQL statements reset STATUS in some versions and not in others. Since }we write a product ported to many machines & versions the above is a safe }way to do things. } }NB define 'rtcd' as INTEGER } }-- }============================================================================ }Sally Woolrich | This mail contains my personal }sally@excelsis.demon.co.uk | views not those of my employer! }============================================================================