db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Korneliussen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Lukket: (DERBY-1172) incorrect error message in updateRow() after a commit on a held scroll insensitive resultset
Date Tue, 11 Apr 2006 08:37:40 GMT
     [ 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


Mime
View raw message