[ http://issues.apache.org/jira/browse/DERBY-628?page=all ]
Satheesh Bandaram updated DERBY-628:
------------------------------------
Attachment: DERBY-628
I have a patch for this issue. I wondered if Derby should also allow setNull on
blob column from binary types.
But Derby behaves differently for blob and clobs in SQL:
ij> create table clobBlob(c clob, b blob, v varchar(10), vb varchar(10) for bit
data);
0 rows inserted/updated/deleted
ij> insert into clobBlob(c) select v from clobBlob;
0 rows inserted/updated/deleted
ij> insert into clobBlob(b) select vb from clobBlob;
ERROR 42821: Columns of type 'BLOB' cannot hold values of type 'VARCHAR () FOR
BIT DATA'.
ij>
> 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: DERBY-628, 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
