You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Andreas Korneliussen (JIRA)" <de...@db.apache.org> on 2006/04/11 10:37:40 UTC
[jira] Lukket: (DERBY-1172) incorrect error message in updateRow()
after a commit on a held scroll insensitive resultset
[ http://issues.apache.org/jira/browse/DERBY-1172?page=all ]
Andreas Korneliussen closed DERBY-1172:
---------------------------------------
> 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
> Fix For: 10.2.0.0
> 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