You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Rick Hillegas (JIRA)" <de...@db.apache.org> on 2006/09/19 17:25:22 UTC
[jira] Updated: (DERBY-1312) refreshRow behavior not the same in
Derby client and embedded drivers
[ http://issues.apache.org/jira/browse/DERBY-1312?page=all ]
Rick Hillegas updated DERBY-1312:
---------------------------------
Fix Version/s: 10.2.2.0
(was: 10.2.1.0)
Moving to 10.2.2.0.
> refreshRow behavior not the same in Derby client and embedded drivers
> ---------------------------------------------------------------------
>
> Key: DERBY-1312
> URL: http://issues.apache.org/jira/browse/DERBY-1312
> Project: Derby
> Issue Type: Improvement
> Components: JDBC, Network Client
> Affects Versions: 10.1.1.0, 10.2.1.0, 10.1.2.0, 10.1.1.1, 10.1.1.2, 10.1.2.1, 10.1.3.0, 10.1.2.2, 10.1.2.3, 10.1.2.4
> Reporter: Dag H. Wanvik
> Priority: Minor
> Fix For: 10.2.2.0
>
>
> In the embedded client, ResultSet#refreshRow throws a not implemented
> exception. In the client driver, it is implemented as a no-op (*) for
> the updatable result set types we support, although it has some cruft
> for sensitive result sets - from a previous life?
> (*) Checks are performed to see if the method is callable given the
> state of the result set, but no actual refresh is attempted. This is
> correct for scroll insensitive result sets, btw.
> The client implementation is wrong in another respect: (Quote from
> JDBC 3.0 API javadoc):
> "If refreshRow is called after calling an updater method, but before
> calling the method updateRow, then the updates made to the row are
> lost."
> As far as I can see, since this is implemented as a no-op, this
> implicit update canceling does not happen.
> I think we should reconcile the driver behaviors, probably by having
> the client throw a not implemented exception as well. It is not
> really needed for scroll insensitive result sets.
--
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