Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <343694201.1240872690694.JavaMail.jira@brutus>
Date: Mon, 27 Apr 2009 15:51:30 -0700 (PDT)
From: "Tiago R. Espinha (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-4184) Calling deleteRow() on a ResultSet
 that has been commited throws no error
In-Reply-To: <1896623933.1240516950315.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-4184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703428#action_12703428 ] 

Tiago R. Espinha commented on DERBY-4184:
-----------------------------------------

This does happen for both drivers indeed. I also tested fetching the data from a row after a commit and the data is there.

I should add that the original master test on which I found this creates the cursor 'with hold'. This is why I am using HOLD_CURSORS_OVER_COMMIT.

However, this is also something that intrigues me. If the cursor is being held over the commit, shouldn't it keep its position over the commit call?

I mean, as it is, it isn't keeping the position and the holdCursorJDBC30.out relies on this fact, but it just feels a little counter-intuitive. The cursor is created with hold but it doesn't really hold the position.

Does this mean that the hold clause would only work for read-only cursors?

> Calling deleteRow() on a ResultSet that has been commited throws no error
> -------------------------------------------------------------------------
>
>                 Key: DERBY-4184
>                 URL: https://issues.apache.org/jira/browse/DERBY-4184
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Server
>    Affects Versions: 10.6.0.0
>         Environment: Not relevant.
>            Reporter: Tiago R. Espinha
>            Priority: Minor
>         Attachments: ReproHoldCursorBug.java
>
>
> This issue was originally found on DERBY-3839.
> The steps to get this error happening are as follows:
> 1) Set auto commit to false
> 2) Create a Statement with the following parameters:
> ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_UPDATABLE and ResultSet.HOLD_CURSORS_OVER_COMMIT
> 3) Create a ResultSet by having a SELECT on an executeQuery() on a table with at least one row.
> 4) Do a next(); on the ResultSet. Then commit() and try to deleteRow() on the ResultSet.
> According to holdCursorJDBC30.out, the deleteRow() should throw an 'Invalid cursor state - no current row' but it doesn't, not when using Java code.
> The problem here is the ResultSet.CONCUR_UPDATABLE. By setting this property, the ResultSet checks that the property is different from CONCUR_READ_ONLY and doesn't do a proper check on checkForUpdatableResultSet(). Without this check, the deleteRow() executes successfully BUT, the row does NOT get deleted.
> After talking about this with Kathey, we agreed that the exception should always happen. If an exception isn't thrown and the row isn't deleted, then this is certainly misleading

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.