Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!gatech!hao!husc6!necntc!ames!ptsfa!bh From: bh@ptsfa.UUCP (Brian Holliday) Newsgroups: comp.databases Subject: Re: Big fun w/Informix cursors. Message-ID: <3228@ptsfa.UUCP> Date: Fri, 10-Jul-87 14:48:19 EDT Article-I.D.: ptsfa.3228 Posted: Fri Jul 10 14:48:19 1987 Date-Received: Sun, 12-Jul-87 12:09:18 EDT References: <147@paisano.UUCP> <3219@ptsfa.UUCP> <3227@ptsfa.UUCP> Organization: Pacific * Bell, San Ramon, CA Lines: 61 In article <3227@ptsfa.UUCP> ssl@ptsfa.UUCP (Sam Lok) writes >In article <3219@ptsfa.UUCP> bh@ptsfa.UUCP (Brian Holliday) writes: >> >>Declare two cursors -- one that goes forward (let's call it CURSORF), >>and one that goes backwards (let's call it CURSORB). Both cursors use the >>data from the current cursor, and find the next data (there's a ">" >>selection) or previous data (a "<" selection). >> >>To go forward: OPEN CURSORF, FETCH CURSORF, and CLOSE CURSORF. >>To go backwards: OPEN CURSORB, FETCH CURSORB, and CLOSE CURSORB. >> >>Since the cursor has been closed, your second question/problem has also been >>solved. You may update/delete/whatever, and then open up the cursor >>for the next selection. > >Perhaps you might want to enlighten us a bit more on this subject? > >1. How can you associate CURSORF and CURSORB with the 'current cursor' > you mentioned. Is 'current cursor' a third cursor that's required? > I always thought cursors associate with a particular set of select > statement. When CURSORF or CURSORB is FETCHed, the data from the database is extracted, and put into your program's variables. Use one of these program variables to determine what is to be selected. There is no third cursor. I meant the data from the cursor (CURSORF or CURSORB) that had just been FETCHed. (Before the first FETCH, you need to set the program variable to something reasonable, of course.) >2. How can you adjust CURSORF/B to work like perform's next and previous? > You can't really touch cursor, can you? You can use the data brought in from a cursor -- for another cursor. The FETCH extracts data from the database and puts it in your program's variables. You can pick up one of these variables, and use it for another FETCH. >3. The 'ESQL/C' manual says "The CLOSE statement puts the cursor in the closed > state and leaves its active set undefined. To me, it means your next > open and fetch will give you the same row you just read. Of course, > you can put in a while loop so you can go pass your last record and read > the next one in line, but think about how many reads one have to do in > order to go thru a long list of rows makes me wonder if this is all > worth the trouble. Of course, it's would be a different matter if I > misunderstand the manual! From page 7-138 of the Informix 4GL Reference Manual (Volume 2): The OPEN statement examines the content of the program variables and, using these values for the parameters in the SELECT statement, determines the set of rows that satisfies the WHERE clause. This set of rows is called the *active set*. So the OPEN will create a new active set, because the content of the program variable has changed. (Don't confuse this concept of "active set" with the program variables. An "active set" row is copied into the program variables each time a FETCH is done.) Good enough? Brian Holliday {ihnp4,pyramid,qantel}!ptsfa!bh