Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!apple!well!gatynen
From: gatynen@well.sf.ca.us (Gerard Tynen)
Newsgroups: comp.databases
Subject: Re: Oracle CURSORS useless ?
Message-ID: <25782@well.sf.ca.us>
Date: 29 Jun 91 22:57:50 GMT
References: <1991Jun27.230131.2358@world.std.com>
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 24

In article <1991Jun27.230131.2358@world.std.com> epstein@world.std.com (Richard W Epstein) writes:
>In article <25731@well.sf.ca.us> gatynen@well.sf.ca.us (Gerard Tynen) writes:
>>We couldn't think of any reason to force a close on all cursors just
>>because you do a commit.  I think that what happened is that early 
>[deleted...]
>
>A commit by definition makes any updates,inserts, and deleted permanent
>and releases locks. After this happens, where would your cursor point?
>Since you released your locks, you cannot be sure the records or
>even the table is still there or that you have access to them.

I believe that Sybase uses a different defintion of "commit".  You can
open a number of connections and if you commit on one connection, the
other connections are not affected; their changes are still outstanding.
Each connection is actually considered a separate user.

So we were able to use one connection for reading, and another for DML.
We didn't close the cursor, although if an update or insert affected 
the result set, the cursor would have to be reopened to see those changes.
Also we didn't lock what we were reading, so yes, I agree with you that
drastic changes could take place in the database and the cursor would not
know anything about it. 

--GT