[ 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
