Description: When filling a field with a fixed character size data type with appropriate data, the field is right padded with spaces to 4 times its defined length. Steps to Reproduce: 1. Create new embedded firebird database 2. Create new table with a CHAR() data field (weather primary key or not) 3. Insert data, save and close table 4. Reopen table Actual Results: All entered data is right padded with spaces to 4 times its set size Expected Results: Spaces shouldn't have been added Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Base gives an error on trying to fill records in a form using a list box linking to that column. Giving this error message: firebird_sdbc error: *Dynamic SQL Error *SQL error code = -303 *arithmetic exception, numeric overflow, or string truncation *string right truncation *expected length 3, actual 12 caused by 'isc_dsql_execute' Version: 7.2.5.2 (x64) / LibreOffice Community Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: en-IE (en_IE); UI: en-GB Calc: threaded
Have tested this with LO 7.3.1.2 and LO 7.2.5.2 on OpenSUSE 15.3 64bit rpm Linux. Spaces have been added because it is a CHAR()-field with defined length. But the length, which is currently added by spaces, will be the wrong length. Looks like a bug with UTF8. Example: To a CHAR(10) field with 10 characters will be added 30 spaces.
*** Bug 120640 has been marked as a duplicate of this bug. ***
This is wontfix in the firebird bug tracker. The devs there don't consider it to be a bug - the function is working as designed as it is related to the character encoding, so padding occurs according to the number of bytes in which any given character is written.
I thought it would be enough to set the UTF8 character set to the connection string. Apparently, this is already the case in Connection::construct [1]. I tried to just divide the sqllen by 4 (UTF8 ) in firebird::mallocSQLVAR [2] but it does not work because system queries sometimes return not a multiple of 4. Maybe the tables and columns were created a different character set. [1]https://opengrok.libreoffice.org/xref/core/connectivity/source/drivers/firebird/Connection.cxx?r=840b4eb2#222 [2]https://opengrok.libreoffice.org/xref/core/connectivity/source/drivers/firebird/Util.cxx?r=3a88b513#296
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: firebird_sdbc error: *Dynamic SQL Error *SQL error code = -303 *arithmetic exception, numeric overflow, or string truncation *string right truncation *expected length 3, actual 12 So it counts the right length together with the spaces. But if I delete the just added (4.) character it will save the content.
(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.