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