Based on this assumption, I see three possible ways to go:
In theory (i. e. with jdk1.4 and conforming drivers) stmt.setNull(i + 1, stmt.getParameterMetaData().getParameterType(i + 1)); should provide the correct type for the null value.
In practise, any type might be better than Types.OTHER. I can imagine two approaches
used by the driver:
- ignore the type, then any typecode is as good as Types.OTHER
- verify the typecode: then is certainly has to be a type supported by the database
and (not knowing the correct type) ideally one that can be converted to the
columns real type. In this case, the best choice will probably be Types.VARCHAR.
As an alternative to trying to guess the correct type, there could be typed null-values
that can optionally be used by a client of QueryRunner. Something along the lines
public class Nulls {
public static final Nulls VARCHAR = new Nulls(Types.VARCHAR);
....
public int getType() {...}
}
and in fillStatement
if (params[i] instanceof Nulls) {
setNull(i+1, ((Nulls) param[i]).getType());
} else if (params[i] != null) {
setObject
} else {
setNull
}Ronald
It would be nice if every driver accepted null in setObject but I don't think that's the case. If we could find a common way to set null parameters in DB2, Oracle, SQL Server, MySQL, and Postgres we could implement fillStatement to use it. Until then, the QueryRunner subclass approach is the only solution.
David
[...]
My solution was create a QueryRunner subclass, where I overridden fillStatement() method like this:
if (params == null) { return; }
for(int i = 0; i < params.length; i++) { stmt.setObject(i + 1, params[i]); }
[...]
<>Thanks,
Rafael Ubiratam Clemente Afonso [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
