Re: Informix Bug: Fetch Last

Daniel Wright wrote: > > 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.) [Heartfelt diatribe on experience we all shared snipped] In some early 5.0x version development decided that the delay for the OPEN to return until the first buffer from the query was ready, or the temp table complete in the case of a SCROLL CURSOR, was unacceptable and deferred the actual processing of the query to the first FETCH. Obviously there is a bug in FETCH LAST that fails to trigger the initial query. I will not comment on the remainder of your post because I'll just fog up my monitors with the steam that will begin to stream from my ears! I'll just say that you speak for us all. Art S. Kagel