Scott Lamb <slamb@slamb.org> writes:
> First, my understanding is that cursors are only valid within the
> transaction in which they were created. Is this correct?
>
> If so, I can't use the cursor method exclusively. Some of my code needs
> to be able to iterate over a resultset and execute whole transactions
> based on it. With cursors, it would fail after the first iteration of
> the loop.
>
> From the archives, Barry Lind's plan at one point was to not use
> cursors unless setFetchSize() was used explicitly. [*] That would keep
> existing code working. Or otherwise, they should not be used if I
> specify ResultSet.HOLD_CURSORS_OVER_COMMIT; I could add that to my code
> where it is important. If/when the backend changes to support holding
> cursors over commit, then they could be used in all cases.
>
> Does this sound reasonable?
I've been thinking about it this morning... I think that we're going
to have to drop the idea of keeping the cursor open and go with the
idea suggested earlier (sorry, I forget by who) of issuing multiple
SQL statements slightly hacked to limit the row set.
Otherwise it's just not going to fly with multiple statements.
Nic
