This is an example where we find our code throwing the wrong SQL State,
but are we allowed to fix it? Lance says yes. Others providing support
for customers say (I think) no.
This ties into the discussion about the stability classification for SQL
States. If we mark it as Stable, then we can't change this. If we mark
it as Unstable, then we can.
Comments, thoughts?
David
Andreas Korneliussen (JIRA) wrote:
[ 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.
