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 Army <qo...@sbcglobal.net> on 2005/10/14 02:36:07 UTC
setNull() using Types.VARCHAR for a CLOB parameter fails in embedded
mode.
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).
Can anyone confirm one way or the other? If I don't hear otherwise, I'll file a
Jira issue tomorrow.
Thanks,
Army
Re: setNull() using Types.VARCHAR for a CLOB parameter fails in embedded
mode.
Posted by Army <qo...@sbcglobal.net>.
Army wrote:
> 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.
[ snip ]
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 the other
character types, so it seems like the above method should have similar logic.
Unless CLOB was intentionally left off for some reason...?
In any event, my original intent stands: if I hear no objections, I'll file a
Jira bug tomorrow.
Army