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 21:56:30 GMT

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

Dag H. Wanvik commented on DERBY-4184:

I seem to remember that for scrollable, updatable result sets, we discussed whether to require
a repositioning after commit or not, but I forget the
Does this work the same on both drivers? (even without a delete row, is the can you get data
from the row after a commit on both drivers without repositioning)?
In any case, I agree this looks like a bug...

> 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