Re: [jira] Commented: (DERBY-1938) Add support for setObject(, null)

[Lance J. Andersen]

The following wording was added to the JDBC 4.0 javadocs to address this issue: Note: Not all databases allow for a non-typed Null to be sent to the backend. For maximum portability, the setNull or the setObject(int parameterIndex, Object x, int sqlType) method should be used instead of setObject(int parameterIndex, Object x). Daniel John Debrunner (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1938?page=comments#action_12440912 ] Daniel John Debrunner commented on DERBY-1938: ---------------------------------------------- Section 13.2.2.2 does not apply here. Since Java null has no type it cannot be mapped using this rule: "the Java Object mapped using the default mapping for that object type. " I think the real justification for changing setObject(col, null) seems be to match other JDBC drivers (which ones?) and/or applications that seem to expect this to work. But there's liittle evidence of that justification in this thread. I think it's clear that the JDBC spec (from the tutorial) indicates that applications should not depend on this behaviour. Add support for setObject(<arg>, null) -------------------------------------- Key: DERBY-1938 URL: http://issues.apache.org/jira/browse/DERBY-1938 Project: Derby Issue Type: Improvement Components: JDBC Reporter: Dag H. Wanvik Assigned To: Tomohito Nakayama Priority: Minor Attachments: DERBY-1938.patch Derby presently does not implement support for the method PreparedStatement.setObject (and similarly for CallableStatement.setObject) when the supplied value is null, unless a type argument (3rd arg) is also present. That is, in: void setObject(int parameterIndex, Object x) throws SQLException x can not be null. Derby will presently throw an SQLException (client: XJ021, embedded: 22005) if x is null when calling this method on a preparedStatement. Porting some applications may be made easier if this restriction is lifted. See also discussion in DERBY-1904.