Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!husc6!cmcl2!beta!hc!ames!ptsfa!ssl
From: ssl@ptsfa.UUCP (Sam Lok)
Newsgroups: comp.databases
Subject: Re: Big fun w/Informix cursors.
Message-ID: <3227@ptsfa.UUCP>
Date: Fri, 10-Jul-87 11:16:42 EDT
Article-I.D.: ptsfa.3227
Posted: Fri Jul 10 11:16:42 1987
Date-Received: Sun, 12-Jul-87 11:46:10 EDT
References: <147@paisano.UUCP> <3219@ptsfa.UUCP>
Reply-To: ssl@ptsfa.UUCP (Sam Lok)
Organization: Pacific * Bell, San Ramon, CA
Lines: 49

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.

2.  How can you adjust CURSORF/B to work like perform's next and previous?
    You can't really touch cursor, can you?

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!

And now back to the original poster question about update trashing cursor.
Although I never had a need to update multiple rows in a shot, I do always
use: declare cursor for update, open, fetch, update where current of
sequence.  The manuals says "If you use the CURRENT OF option in the WHERE
clause, ESQL/C updates the current row of the active set and leaves the
cursor on the same row.  You may UPDATE only those columns that you 
previously listed in the FOR UPDATE clause of the DECLARE statement that
defined cursor-name."  And if the cursor really got trashed after the update,
I think it's a bug for RDS, oops, Informix, Inc.  Also, as I was told by
Informix, you'll have to use the 'declare .. for update' syntax if you want
to lock the rows.
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Sam Lok		San Ramon	  {ihnp4,pyramid,qantel}!ptsfa!ssl
				|| To err is human, to really foul things
I disclaim my disclaimer!	|| up requires super-user privilege!