https://bugs.documentfoundation.org/show_bug.cgi?id=147893
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #6 from [email protected] --- (In reply to Robert Großkopf from comment #5) According with Fire3bird 3.0 Language Reference pdf: ``` 3.5.1. Unicode Most current development tools support Unicode, implemented in Firebird with the character sets UTF8 and UNICODE_FSS. UTF8 comes with collations for many languages. UNICODE_FSS is more limited and is used mainly by Firebird internally for storing metadata. Keep in mind that one UTF8 character occupies up to 4 bytes, thus limiting the size of CHAR fields to 8,191 characters (32,767/4). The actual “bytes per character” value depends on the range the character belongs to. Non-accented Latin letters occupy 1 byte, Cyrillic letters from the WIN1251 encoding occupy 2 bytes in UTF8, characters from other encodings may occupy up to 4 bytes. ``` > CHAR_LENGTH() will give the expected value for type CHAR. It will be the > same value as defined in the table. But the field will be filled with spaces > like it would have if using "normal ASCII". So a field defined for length 3 > has 3 defined characters and 9 spaces. There will appear an error if I try > to input 4 characters in such a field: Not totally agree. If UTF8 is used (default for Firebird in LO), if you define 3 characters length, the field can contain until 12 **bits** but only 3 **characters**, even if the character is stored in one or two bits > *expected length 3, actual 12> > firebird_sdbc error: > *Dynamic SQL Error > *SQL error code = -303 > *arithmetic exception, numeric overflow, or string truncation > *string right truncation > This confirms my previous statement. I think this is not a bug, any case it's not or bug. -- You are receiving this mail because: You are the assignee for the bug.
