[ 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: 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
