[ https://issues.apache.org/jira/browse/DERBY-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13168517#comment-13168517 ]
Dag H. Wanvik edited comment on DERBY-5534 at 12/13/11 5:20 PM: ---------------------------------------------------------------- Offline, Knut alerted me to the fact that related to this issue is the fact that the DB2 limits enforced by the Derby engine, are also not checked by the client on rs#updateXXX, but is only seen when rs#updateRow is performed as an error returned from the server. If we choose to lift the DB2 specific restriction (cf. DERBY-3398), this asymmetry would disappear though. was (Author: dagw): Related to this issue is the fact that the DB2 limits enforced by the Derby engine, are also not checked by the client on rs#updateXXX, but only when rs#updateRow is performed. If we choose to lift the DB2 specific restriction (cf. DERBY-3398), this assymmetry would disappear though. > ResultSet#updateFloat, #updateDouble do not check for NaN on client > ------------------------------------------------------------------- > > Key: DERBY-5534 > URL: https://issues.apache.org/jira/browse/DERBY-5534 > Project: Derby > Issue Type: Bug > Components: JDBC, Network Client > Reporter: Dag H. Wanvik > Priority: Minor > > In updateXXX, where XXX is one of Float or Double, embedded throws value out > of range when the argument is Float.NaN or Double.NaN, the client does not > catch it. > The server will balk when the row is updated, though, in ResultSet#updateRow. > It will be more regular if this is caught in updateXXX also on the client as > other range errors are. The SQL state seen is 22003, which is what embedded > throws on updateXXX. See also DERBY-5533. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira