> Turns out the person that put the commit there had requested a
> read-write, scrollable cursor (something I'd suggested to the team
> we don't do, as the docs suggested the JDBC driver [or database] did
> not support it). Anyway, with the commit and this combo of settings,
> they were able to call ResultSet.last(), get the number of rows in
> the ResultSet, then call ResultSet.first() and then iterate thru
> them. They weren't able to do a last() then first() unless they
> added the commit immediately after running the query.
>
> We took out the commit (it made no sense to have it there), and
> (ignoring any other last() first() issues), the error doesn't occur
> any more!

Strange... When you ask for read-write scrollable cursor, you should get
warning in the connection and your cursor should be read-only and
TYPE_SCROLL_INSENSITIVE. This also means that the complete result set is
cached in memory and does not need server anymore.

When you do the commit, the cursor from the result set is automatically
closed. Any subsequent fetch leads to the error you had. But since your
cursor is TYPE_SCROLL_INSENSITIVE, you should not notice that.

> Does this help highlight any database error?

I will be very grateful if you can create a test case that reproduces the
issue you had.

> Or is it more to do with the issue discussed above where there's a bug in
> GDSException so we aren't seeing an appropriate message?

With that test case I will be able to fix that bug in GDSException too,
though, as I already told you, it is not critical and has no influence on
the behavior of the driver.

Roman

> Yahoo! Groups Links