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, 02 May 2006 20:22:04 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1251?page=comments#action_12377466 ] 

Andreas Korneliussen commented on DERBY-1251:

Withdrawing the patch DERBY-1251.diff.

It turns out that the currentRow attribute in the EmbedResultSet may in certain combinations
of scrolling refer directly to a row in the hashtable of a ScrollInsensitive ResultSet.  updateXXX()
methods then get to write into the hashtable. When doing cancelRowUpdates(), EmbedResultSet
copies over its internal reference to the columns, however the data in the hashtable may still
have been modified by updateXXX. This patch simply reveals this problem more clearly, as this
situation may occur every time one do cancelRowUpdates. I will work on a patch to completely
remove this problem.

> 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
>  Attachments: DERBY-1251.diff, DERBY-1251.stat, derbyall_report.txt
> 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