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_) {
updateRowCalled_ is set to true in updateRow().

Seems most of this logic is relaxed on having the resultset becoming unpositioned after an

> 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:
>     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:
For more information on JIRA, see:

View raw message