DB2 Parameter binding for literal comparisons

Question

I've got SQL for DB2 of the following abbreviated format:

Select ...
From ...
Where ... ((COL1 IS NULL) And ('' = ?)) ...
Order By ...

The rough purpose of this SQL is to return Null records if the input against COL1 is blank.

However, if I try to bind 'RED' to the placeholder, I get a CLI0109E error indicating 'string data right truncation.' I believe what is happening is that DB2 has decided that the '' literal in the SQL is a column of length 0, and so trying to compare a bound parameter of length 3 (in the case of 'RED') causes the truncation error. This would make sense.

If I change the SQL to: ((COL1 IS NULL) And ('{10 spaces}' = ?)), it works fine.

If I change the SQL to: ((COL1 IS NULL) And (CAST('' AS VARCHAR(32767)) = ?)), it works fine.

Is there a driver setting, or an SQLBindParameters setting that I'm missing that's causing DB2 to interpret the '' as a zero-length column?

I run the same SQL through Oracle and SQLServer and they work fine, which tells me they interpret '' as something different, and maybe by default treat all literals in the SQL as VARCHAR(32767) or something.

Thanks for any help.

Answer 1

The answer to this question seems to be that this is the way DB2 works when determining the data type and size for the literal.

From what I've found out, the concepts to understand here seem to be implicit and explicit CASTing. Since no explicit CAST was provided for the empty string literal, and there was no further information available on the right-hand side of the comparison predicate (only the parameter placeholder is present and it provides no definite size information), DB2 will implicitly cast to the size of the literal, in this case CHAR(1) (or maybe VARCHAR(1), I'm not entirely sure on this point).

So, it's not a CLI driver problem or quirk, nor an SQLBindParameters issue. The explicit CAST of CAST('' as VARCHAR(nn)) seems to be the correct solution to avoid the CLI0109E error.

For what it's worth, based strictly on my experiences, Oracle and SQLServer seem to behave differently than DB2 when running the same SQL on those platforms. Their implicit CASTs, absent any available size information upon which to draw, seem to be VARCHAR(large). But the explicit CAST also works just as well for them.