[jira] Closed: (DERBY-610) After commit, holdable result set cursor used in positioned update can't access row

["Dag H. Wanvik (JIRA)" <de...@db.apache.org>]

     [ http://issues.apache.org/jira/browse/DERBY-610?page=all ]
     
Dag H. Wanvik closed DERBY-610:
-------------------------------

    Resolution: Invalid

Closed this, not a bug. The SQL standard 2003, Part 2: Foundation
(SQL/Foundation) p 827:

>   6) If CR is a holdable cursor and a <fetch statement>has not been
>   issued against CR within the current SQL- transaction,then an
>   exception condition is raised: "invalid cursor state".

That is, a positioning operation is required before the row can be
updated or deleted. Derby implements rowUpdate and rowDelete using
positioned cursor operations and has the same limitation, and will
give the same exception for forward only, updatable result sets. For
Scrollable, updatable insensitive result sets being implemented as
DERBY-690 and DERBY-775, the behavior should be the same. JDBC
doesn't address this requirement, as far as I can tell.




> 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: 10.2.0.0
>     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:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira