db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4184) Calling deleteRow() on a ResultSet that has been commited throws no error
Date Mon, 27 Apr 2009 22:02:30 GMT

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

Dag H. Wanvik commented on DERBY-4184:

The test case testUpdateRowAfterCommitOnHeldScrollInsensitiveResultSet in HoldabilityTest
seems to indicate we decided to require repositioning also this this kind of result set after
a commit.

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

View raw message