Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <737734723.1144052384093.JavaMail.jira@ajax>
Date: Mon, 3 Apr 2006 09:19:44 +0100 (BST)
From: "Andreas Korneliussen (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-1172) incorrect error message in
 updateRow() after a commit on a held scroll insensitive resultset
In-Reply-To: <1686562992.1143810216207.JavaMail.jira@ajax>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/DERBY-1172?page=comments#action_12372897 ] 

Andreas Korneliussen commented on DERBY-1172:
---------------------------------------------

Derbyall test results:
Summary results:

Test Run Started: 2006-03-31 15:15:09.0
Test Run Duration: 04:11:03

643 Tests Run
100% Pass (643 tests passed)
 0% Fail (0 tests failed)
2 Suites skipped

The patch should now be ready for commit.

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

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