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