Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!vrdxhq!grebyn!paisano!demasi
From: demasi@paisano.UUCP (Michael C. De Masi)
Newsgroups: comp.databases
Subject: BIG, BIG fun w/Informix cursors
Message-ID: <229@paisano.UUCP>
Date: Fri, 17-Jul-87 11:21:51 EDT
Article-I.D.: paisano.229
Posted: Fri Jul 17 11:21:51 1987
Date-Received: Sat, 18-Jul-87 17:13:07 EDT
Organization: AT&T Communications.  Fairfax, VA
Lines: 62
Keywords: Not a bug, a feature!

Hello again people,

If you remember my origional posting, I was the guy who was having
so much trouble with Informix cursors.  The two problems I was having
involved:  1)  The fact that they're seemed to be no way to back up
a cursor in an active list after a fetch.  2)  The fact that non-
readonly activity seemed to break every cursor declared in the program
at any given time.  I actually got quite a few kind responses from the
net on the first point, but general confusion on the second.  For the
answer to the second point, I had to consult with tech support at 
Informix.  In summary:

1)  No, there is no real way to back up a cursor in an active list.
The command 'fetch' only works in one direction, and there is no
equivalent of an 'unfetch'.  I did, however, receive several strategies
for getting around this problem, mostly involving creating temporary
tables and/or files with the data or rowids from the given database
tables.  This is pretty much what I was already doing, and was looking
to avoid.  One fellow even suggested declaring two cursors, one going
in ascending and the other in descending order, and querying and
redeclaring them as they approached and overlapped each other.
Also, from what I could glean, these problems are solved in 4GL
with what they call a 'scroll cursor' with which one can issue
commands like 'scroll up' 'scroll back' etc.

2)  As to the second point, I seemed to get a great deal of confusion
from the net regarding my statement of the problem.  Put as simply as
possible, it seemed that non-readonly activity (ie updates, deletes
and insertions) seemed to make any currently declared & opened cursor
in the program inoperative.  The sqlca.sqlcode returned from the next
fetch was -259 'cursor not open'.  Nobody on the net could place the
problem, so again I consulted with Informix.  The problem was not with
the update activity per se, but with the structure placed around it.
To insure data integrity, I had put all update statements within the
context of a 'begin work ... commit work else rollback work' structure.

IMPORTANT:  Both 'commit work' and 'rollback work' have the side effect
of closing every active cursor in the whole damn program!

(FLAME ON!!!)
Now this is not limited to cursors acted upon within the structure, or
indeed to cursors declared for update, but all of them.  The nice person
I spoke to at Informix assured me that this was indeed a documented
feature of both 'commit work' and 'rollback work'.  Documented or not,
I find this a rather bizarre concept.  I thought the purpose of this
structure was to insure transaction integrity, not to do cleanup work
of record locks, etc.  In my humble opinion, this is the kind of thing
best left to the programmer or to the database administrator itself and
should not be hidden within the context of a seemingly non-related
functionality.
(FLAME OFF!!!)  Lord, do I feel better.

Anyway, to be fair to Informix, with the exception of the above probs
(which I'll admit I probably would have avoided if I'd read the doc a
bit more carefully) ESQL/C is a good tool, and has served me well.

Till next time,
-- 
Michael C. De Masi - AT&T Communications (For whom I work and not speak)
3702 Pender Drive, Fairfax, Virginia 22030   Phone: 703-246-9555
UUCP:   seismo!decuac!grebyn!paisano!demasi
     "Life.  Don't tell me about life." - Marvin, the paranoid android