db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Korneliussen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1251) cancelRowUpdates() affects rows updated with updateRow() in scrollable updatable resultsets
Date Tue, 25 Apr 2006 12:40:06 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1251?page=comments#action_12376245 ] 

Andreas Korneliussen commented on DERBY-1251:
---------------------------------------------

Actually, the previous comment indicates another related bug: after updateRow(), rs.getXXX()
returns the old value. 

In addition I found that in the network driver: after doing updateRow(), and you later do
updateXXX() + cancelRowUpdates(), the cancelRowUpdates() does not have any effect, since updateRow()
had been called once on the row.

Due to this logic in org.apache.derby.client.am.ResultSet.cancelRowUpdates() :

                / if updateRow() has already been called, then cancelRowUpdates should have
                // no effect.  updateRowCalled_ is reset to false as soon as the cursor moves
to a new row.
                if (!updateRowCalled_) {
                    resetUpdatedColumns();
                }
updateRowCalled_ is set to true in updateRow().

Seems most of this logic is relaxed on having the resultset becoming unpositioned after an
updateRow().


> cancelRowUpdates() affects rows updated with updateRow() in scrollable updatable resultsets
> -------------------------------------------------------------------------------------------
>
>          Key: DERBY-1251
>          URL: http://issues.apache.org/jira/browse/DERBY-1251
>      Project: Derby
>         Type: Bug

>   Components: JDBC, Network Client
>     Versions: 10.2.0.0
>     Reporter: Andreas Korneliussen
>     Assignee: Andreas Korneliussen
>     Priority: Minor

>
> If an application does the following:
> rs.updateInt(1, newValueCol1);
> rs.updateRow();
> rs.updateInt(2, newValueCol2);
> rs.cancelRowUpdates();
> Then, when calling rs.getInt(1), it will return the old value. Instead it should return
the new value.
> Workaround: after calling rs.updateRow(), the application could call rs.relative(0).
> This problem does not affect forward only resultsets, since after an updateRow() they
get positoned before the next row, leaving it impossible to do anything with the current row.

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


Mime
View raw message