Re: 4GL/Engine: FETCH RELATIVE acting flakey

We do exactly this all the time and it works fine. Are you sure you have described the problem correctly. There are 3 fetches (sortof): You do: open ... fetch first ... # First row read fetch relative 1 ... # Second row read fetch relative 1 ... # Status notfound set but: On the last fetch relative the variables contain the values from the previous fetch. As you now they aren't changed if you get a non sero status. You have to test on status. If it's notfound we do a fetch first or fetch last depending on what way we where going. This was just to avoide any future problems with that last fetch changing the variables. (Defensive programming you know.) From your explanation I understand it as you do this: open ... fetch first ... # First row read fetch relative 1 ... # First row read again fetch relative 1 ... # Second row read fetch relative 1 ... # Status notfound set That's a defect if the other things you say about it are correct. Except: Have you made sure you have prepared/declared the cursor only in one place, and that is on top of the same module where this code is? Although cursors are now theoretically global prepare/declare and all usage should still be in one and the same module. (I am not even sure 4GL will compile if you don't do this.) If you have prepared/declared a cursor with the same name in some totaly unrelated part of your code that may explain such strange behaviour (assuming you use -globcurs). That may also be said to be a defect. An error status should have been set. It isn't though. I doubt you would get Informix to fix this defect as it is only there when you have a defect in your own program. Hope this can help in your search at least. Jacob Salomon <jake@apparel.net> wrote: :Hi family, : :I am having a flaky problem with the FETCH command. I am writing a :classical menu-driven program, with QUERY, NEXT, PREVIOUS menu items. : :When the user calls for QUERY, I initiate the SELECT, declare a cursor :and issue the FETCH FIRST command. When the user presses "NEXT", I :issue the command: FETCH RELATIVE nn cursor_name. Here is a code :snippet: : :function fetch_libdoc(nfetch) :define nfetch smallint : define nparm smallint # Parameter counter : : if nfetch = 0 : then : fetch first libdoc_pk_curs # Effective fetch first : into rp_libdoc.funcname : else : fetch relative nfetch libdoc_pk_curs # Skip to current + : into rp_libdoc.funcname # nfetch rows : end if : :Problem: The first time I issue the FETCH RELATIVE command, it :retrieves the first row of the query all over again! A "select count" :retrieves 2 yet I can successfully run a total of 3 fetches. The form :comes up with [document 3 of 2], clearly ridiculous. : :Answers I have eliminated: : - nfetch is 0 or null : No, I have repeatedly checked this in the debugger before the fetch. : :- I have closed the cursor and reopened it somewhere. : Not possible; it would have aborted the next time I did a fetch. : Just in case, I just grep'ed for the cursor name. My code has not : closed the cursor anywhere. : :- The first row of data is really duplicated : No, I ran SQL on the query. Exactly 2 rows in the active set. : :I have also tried using an unqualified FETCH and FETCH ABSOLUTE 1 for my :initial fetch command. The problem persists! : :Thinking I have found a silly bug, I wrote a small test program to :demonstrate the problem. SURPRISE! I could not replicate it! :My tester issues FETCH FIRST followed by a loop of FETCH RELATIVE. All :data was retrieved as appropriate. : :OK, I've eliminated the obvious. What could I possibly be overlooking? :I need a brainstorming session! : :Thanks for any help. :-- : -- Jake (With a talent for finding showstoppers) : . . : _..-'( )`-.._ : ./'. '||\\\\. }\\_/{ .//||` .`\\. : ./'.|'.'||||\\\\|.. )o o( ..|//||||`.`|.`\\. : ./'..|'.|| |||||\\`````` \\,@,/ ''''''/||||| ||.`|..`\\. : ./'.||'.|||| ||||||||||||. ||| .|||||||||||| ||||.`||.`\\. : /'|||'.|||||| ||||||||||||{ | }|||||||||||| ||||||.`|||`\\ : '.|||'.||||||| ||||||||||||{ | }|||||||||||| |||||||.`|||.` :'.||| ||||||||| |/' ``\\||`` | ''||/'' `\\| ||||||||| |||.` :|/' \\./' `\\./ \\!|\\ /|!/ \\./' `\\./ `\\| :V V V }' `\\ /' `{ V V V :\\ \\ \\ V / / / :+-----------------------------------------------------------+ :| Impeccable Logic: A thought process which successfully | :| resists chicken bites | :+-----------------------------------------------------------+ Nils.Myklebust@idg.no NM Data AS, P.O.Box 9090 Gronland, N-0133 Oslo, Norway My opinions are those of my company The Informix FAQ is at http://www.iiug.org