[ http://issues.apache.org/jira/browse/DERBY-1172?page=all ]
Andreas Korneliussen updated DERBY-1172: ---------------------------------------- Attachment: DERBY-1172.diff DERBY-1172.stat The attached patch addresses the bug by catching and rethrowing. It also extends jdbcapi/HoldabilityTest.junit with two testcases which verfies that the correct exceptions is given. > incorrect error message in updateRow() after a commit on a held scroll > insensitive resultset > -------------------------------------------------------------------------------------------- > > Key: DERBY-1172 > URL: http://issues.apache.org/jira/browse/DERBY-1172 > Project: Derby > Type: Bug > Components: SQL > Versions: 10.2.0.0 > Reporter: Andreas Korneliussen > Assignee: Andreas Korneliussen > Priority: Minor > Attachments: DERBY-1172.diff, DERBY-1172.stat > > If an application does updateRow() right after a commit on a held cursor, > (without repositioning the cursor), an incorrect error message is given if > the ResultSet is of type TYPE_SCROLL_INSENSITIVE. > "SQL 2003, Part 2: Foundation (SQL/Foundation) p 827, > paragraph numbered 6): > 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 . > and that exception has state 24000" > Currently, if the ResultSet is of type TYPE_SCROLL_INSENSITIVE, it fails with > SQL Exception: The scan is not positioned. state: XSCH7 : code=20000 > If the ResultSet is of type TYPE_FORWARD_ONLY, it gives the correct error > message: > SQL Exception: Invalid cursor state - no current row. state: 24000 : > code=20000 > The first exception is given from the store layer. The SQL layer seems to > catch the store exception and rethrow a new exception with correct SQL state > and error message. However this is not done in > TableScanResultset.getRowLocation(), which is used by scrollinsensitve > cursors. > A fix could be to add this logic into TableScanResultset.getRowLocation(). Or > alternatively, make the store layer throw the expected exception, and remove > logic to rethrow the exception. -- 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