[ http://issues.apache.org/jira/browse/DERBY-610?page=comments#action_12331678 ]
Daniel John Debrunner commented on DERBY-610: --------------------------------------------- I think the current behaviour is correct. After a commit the result set is open but is not positioned on a row. The result set must be re-positioned with a next() or other method before acessing a row or modifying it with a positioned update or delete. I think this may be from the SQL standard, or is it the JDBC standard? The bug 4515 (Cloudscape bug tracking system) was fixed, I think to return the correct error as you are seeing. > 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
