>> Please CMIIW:
>> Worst case scenario: someone with 16 varchar fields SELECTs (casted to
>> varchar(4000) behind the scene) will inexplicably fail in jooq/firebird?
>
> Right now, probably yes. Of course, if this is about bind values, jOOQ
> could cast them to the actual string length. E.g.
>
> // CAST(? AS VARCHAR(3)) for
> stmt.setString("abc");
>
> // CAST(? AS VARCHAR(10)) for
> stmt.setString("1234567890");
>
> I'll have to play around with that. If this works, then you're as
> likely to break the 64k limit with jOOQ as with JDBC directly. I guess
> Firebird users could live with that. I'll track this as #1727:
> https://github.com/jOOQ/jOOQ/issues/1727
This seems to work nicely for all of the following SQL dialects (which
need bind value casting): DB2, Derby, Firebird, H2, HSQLDB, CUBRID,
Sybase SQL Anywhere. There's a little catch when non-7-bit-ASCII
characters are involved. By default, the VARCHAR length is measured in
bytes in most databases, not in characters, although I didn't manage
to find the relevant section in the SQL standard documents specifying
this. jOOQ currently has no knowledge of character sets and/or
collations, so the most reliable way of calculating VARCHAR lengths
for bind value casting might be this:
----------------------------------------------------------
public static int varcharLength(String value) {
int length;
// Characters fit in one byte
if (containsOnlyASCIICharacters(value)) {
length = value.length();
}
// Characters can take as many as 4 bytes
else {
length = 4 * value.length();
}
// Derby, DB2 max varchar length
return Math.min(32672, length);
}
----------------------------------------------------------
Any comments, corrections, doubts?
