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!