db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Can we change SQL State? (was Re: [jira] Updated: (DERBY-1172) incorrect error message in updateRow() after a commit on a held scroll insensitive resultset)
Date Fri, 31 Mar 2006 17:39:00 GMT
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?


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
>>         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
>>"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
>>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.

View raw message