> Oddly enough. It seems to require 28 OCTETS characters to hold 16
> bytes.
> Not sure how that match works out.
> ...
> OCTETS works but I think there is a problem with calculating the
> field length. If the field is 16 characters (the length of an MD5) I
> get a data truncation exception while 32 works. Maybe it splits each
> byte into a character of 128 bits instead of 256?

Hmmm... that's a "joke" of our encoder because your connection
encoding is UNICODE_FSS... I'm afraid there's no chance to fool it.
The only choice for you would be to modify line

field.sqldata = field.encodeString(value,javaEncoding);

into

field.sqldata = value;

in body of FBStringField.setBytes(int, byte[]) method.

Sorry.... I will modify version in HEAD branch, but if you use 1.0
release, you should fetch release version from the CVS.

Blas, should we consider this a bug or a feature? Currently
FBStringField.setBytes(byte[]) is used only in
FBStringField.setBinaryStream(InputStream) method. I see no point to
force encoing in that method. Also it is not consistent with
FBStringField.getBytes() method. What do you think?

Best regards,
Roman Rokytskyy