[ http://issues.apache.org/jira/browse/DERBY-628?page=all ]
Satheesh Bandaram reassigned DERBY-628:
---------------------------------------
Assign To: Satheesh Bandaram
> setNull() using Types.VARCHAR for a CLOB parameter fails in embedded mode.
> --------------------------------------------------------------------------
>
> Key: DERBY-628
> URL: http://issues.apache.org/jira/browse/DERBY-628
> Project: Derby
> Type: Bug
> Components: JDBC
> Reporter: A B
> Assignee: Satheesh Bandaram
> Priority: Minor
> Fix For: 10.2.0.0
> Attachments: setNull.java
>
> If I attempt to call PreparedStatement.setNull() and specify Types.VARCHAR
> when the actual parameter type (as determined at bind time) is CLOB, Derby in
> embedded mode will throw an error, while Derby in client/server mode will
> succeed.
> Ex. running the following code:
> st.execute("create table t1 (c clob)");
> PreparedStatement pSt = conn.prepareStatement(
> "insert into t1 values (?)");
> try {
> pSt.setNull(1, Types.VARCHAR);
> pSt.execute();
> System.out.println("Error did NOT reproduce.");
> } catch (SQLException se) {
> System.out.println("Error reproduced:");
> se.printStackTrace();
> }
> Against Derby embedded, the result will be:
> Error reproduced:
> SQL Exception: An attempt was made to get a data value of type 'CLOB' from
> a data value of type 'VARCHAR'.
> But against the Network Server, everything works fine. Derby embedded will
> work in other cases where compatible types are used (ex. using setNull() with
> Types.INTEGER for a BIGINT parameter), but fails for this particular
> situation. Thus I'm assuming this is _not_ intentional (i.e. that the above
> code should work).
> Looks like the problem is in iapi.types.DataTypeDescriptor:
> private static boolean isCharacterType(int jdbcType) {
> switch (jdbcType) {
> case Types.CHAR:
> case Types.VARCHAR:
> case Types.LONGVARCHAR:
> return true;
> default:
> return false;
> }
> }
> I think CLOB should be included in this list, too, shouldn't it? In
> iapi.types.TypeId, "isStringTypeId" is true for CLOBs as well as for the
> other character types, so it seems like the above method should have similar
> logic.
--
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
