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