Re: cursor "jdbc_curs_1" does not exist

tmp@nitwit.de wrote:

>>The current driver will throw an exception if you try this, as
>>HOLD_CURSORS_OVER_COMMIT is not supported (actually, it throws in *all*
>
>
> :-(
>
> Is there a schedule when it will be supported?

No schedule. Patches are welcome. I suggest you look in the archives
first -- there has been lengthy discussion of the various tradeoffs
involved in SCROLL vs. NO SCROLL and WITH HOLD vs. WITHOUT HOLD.

> But the following also doesn't work:
>
> final Statement select = db.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,
> ResultSet.CONCUR_READ_ONLY);

What behaviour did you expect here? IIRC, the default holdability is
CLOSE_CURSORS_ON_COMMIT.

> So I really wonder how I should solve my problem other than calling commit()
> once at the very end...

Options that spring to mind:

- Commit once at the end, as you suggest. I'd do this unless there's a
real advantage in breaking it into smaller transactions.
- Use a fetchsize of 0 which will disable cursors and cache the entire
resultset in memory. That's not going to work well if you have a large
resultset.
- Use a separate connection for the insert transactions; as transaction
state is per-connection, committing an insert transaction won't
invalidate resultsets obtained from the other connection.

-O