Informix Bug: Fetch Last
Posted in 1997
I just had to mention this since it came up again tonite... On v7.22.UC1 (and if memory serves, also on v7.21.UC1), doing a FETCH LAST immediately after OPENing a cursor generates a SQLCODE of -407 (meaningless error message...check versions and call Informix Support if it recurs) Arguably doing a FETCH LAST immediately after OPENing a cursor is stupid (why didn't we change the ORDER BY?), but it happened (or happens), and there is nothing wrong with that logic. The quick fix is to to do a regular FETCH before the FETCH LAST. Apparently Informix is doing something on the initial FETCH, which I have a gut feeling should have been done by the OPEN. (I'm guessing again, but maybe Informix thought they could be more efficient by not performing some operations until a FETCH was done, but IMHO, it's your own stupid fault if you OPEN a cursor and never FETCH from it...at any rate, that processing seems not to be handled by FETCH LAST.) This brings to mind a problem I experienced long ago in Std. Engine days, with SCROLL CURSORS, which is too vague in memory to relate here, but it had something to do with FETCH NEXT or FETCH PREVIOUS after the last row. Does Informix have a weak point here? I really expect much more out of v7.xx of Online! This particular bug could have caused one of our programmers to waste several hours, verifiying that we had all the correct versions of Informix installed in the proper order, and then contacting Tech Support, only to have them admit (after at least an hour of inevitable doubt on their part that we had proper versions) that there was a known bug, which is corrected in a maintenance release, which will be issued very soon (OK, they said within a month or 2 last Spring, but that was on 7.21, and this machine was running 7.22!). Shouldn't Informix's QA dept. include a full complement of FETCH's on Scroll cursors before they release something? [I'm hoping you're listening Jonathan Leffler, and any other Informix employees who lurk this group.] [ Why is it that it takes Informix Tech Support so much convincing that there really is a problem?!?!? It seems that they believe they are infallible and all their customers are idiots. I find it very insulting, as well as a waste of time. If I can incontrovertibly demonstrate that their database engine choked using their own transaction log, that is not good enough. I must provide them with a small program which they can run from the command line which repeatedly reproduces the bug....oh yeah, in the best of all possible worlds too.] Billable hours are very important to us, and unfortunately Informix Bugs are NOT billable! Perhaps we should write this into our next sales contract, that any time spent tracking down Informix bugs be chargable back to Informix (Informix would still make money, but I imagine one of our customers (who happens to have a corporate wide Oracle license, yet still bought our software), would have received it for next to nothing. (This was a different story, different bug, which I spent an entire week isolating before Informix Tech Support would even look at, and even then they bitched about the fact that my test case contained too many lines of code...It was still their bug, not ours!) -- - Danny Wright danwright@bigfoot.com #include <stddisclaimers.h> Idiot, n.: A member of a large and powerful tribe whose influence in human affairs has always been dominant and controlling. - Ambrose Bierce, "The Devil's Dictionary"