> YES! Changing the column's type to VARCHAR(1) works.
>
> Now can someone tell me why? Doesn't my experience still indicate that
> there is some sort of bug with columns of type CHAR(1)?
The language spec is a bit confusing with respect to the what the "n"
actually means in CHAR(n). My copy says something like this:
Name Size Range/Precision
--------- ------------ ----------------------------------------
CHAR (n) n characters 1 to 32,767 bytes
Character set character size determines
the maximum number of characters that
can fit in 32K
So it says that "n" represents the number of *characters*, while the maximum
range is "32,767 *bytes*".
Because one UTF-8 character may take between 1 and 4 bytes, perhaps the
server allocates four bytes of storage for it, even though the character
that is actually stored is only 1 byte?
It seems like a bug to me, though. That the server *allocates* 4 bytes seems
reasonable, however I don't think it should be *returning* 4 bytes (unless
actually required).
Dean.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
