db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew McIntyre (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1172) incorrect error message in updateRow() after a commit on a held scroll insensitive resultset
Date Fri, 31 Mar 2006 21:11:09 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1172?page=all ]

Andrew McIntyre updated DERBY-1172:

    Other Info:   (was: [Patch available])
    Derby Info: [Patch Available]

> 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:
>     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:
For more information on JIRA, see:

View raw message