Nic Ferrier wrote:
> Scott Lamb writes:
> >I'm not sure that would work anyway. It's ResultSet.setFetchSize(),
> >which means you must already have a resultset when to change it. So it
> >seems like it'd be a little late for deciding how to execute the
> >query.
>
>
> We don't use that "setFetchSize" we use Statement.setFetchSize.
Ahh. Didn't realize there were two. That should work, though I still
prefer specifying the required holdability because that's what defines
whether or not you're able to use the (otherwise superior) cursor method.
> >>Note also that CLOSE_CURSORS_AT_COMMIT is not actually a result set
> >>type so it _might_ break other code.
> >
> >Not sure what you mean. If client code is using CLOSE_CURSORS_AT_COMMIT
> >and expecting them to work beyond commit, it's their bug and an
> >easily-fixed one at that. And I don't see any other negative
> >consequences to using cursors, just the advantage of being able to
> >handle large queries.
> [...]
> So CLOSE_CURSORS_AT_COMMIT is not a _normal_ value for the ResultSet
> _type_ type.
Okay, I understand now. The confusion is, you wrote this:
Statement st = connection.createStatement(
ResultSet.CLOSE_CURSORS_AT_COMMIT,
ResultSet.CONCUR_READ_ONLY);
but evil gnomes changed the bits in my copy of the email to what I
expected, so I didn't notice a difference. ;) I meant this:
Statement st = connection.createStatement(
ResultSet.TYPE_FORWARD_ONLY,
ResultSet.CONCUR_READ_ONLY,
ResultSet.CLOSE_CURSORS_AT_COMMIT);
Type, concurrency, and holdability are all orthogonal parameters to
createStatement and prepareStatement.
Thanks,
Scott