db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-610) After commit, holdable result set cursor used in positioned update can't access row
Date Mon, 10 Oct 2005 03:12:48 GMT
    [ http://issues.apache.org/jira/browse/DERBY-610?page=comments#action_12331677 ] 

Dag H. Wanvik commented on DERBY-610:

It seems this is the same bug that is mentioned in test case ten, in HoldCursoIJ.sql.
There it is being referred to as number  4515, probably predating JIRA.

> After commit, holdable result set cursor used in positioned update can't  access row
> ------------------------------------------------------------------------------------
>          Key: DERBY-610
>          URL: http://issues.apache.org/jira/browse/DERBY-610
>      Project: Derby
>         Type: Bug
>   Components: SQL
>     Versions:
>     Reporter: Dag H. Wanvik
>     Priority: Minor
>  Attachments: Main.java
> Using the embedded driver, with autocommit off, and holdability for a
> updatable result set  (HOLD_CURSORS_OVER_COMMIT), I first
> position on a row in the result set, and then commit the
> transaction. The result set should still be open since holdability is
> active.  However, when accessing the result set using a named cursor
> in a subsequent "Positioned update" statement, Derby returns an error
> message: "Invalid cursor state - no current row" (SQLState 24000).
> Please see the self-contained repro case in the attachment for
> details.
> It appears the problem is related to reopening of holdable result sets
> after a commit. During normal use of result sets, the ResultSet#next()
> operation will make sure the result set is opened (after locks were
> released at commit time). Apparently no such reopening is performed in
> the "positioned update" case. (small detail: Note that in the
> "positioned update" case, the reopening is for accessing the current
> row (again), not the next - I am not sure if that matters, though).

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message