Version 5.4 beta1. Locale RU Create a table with a field length of 5 and a VARCHAR. Enter in data mode (grid) this field is a string 20 characters long. Create a table with a field length of 5 and a VARCHAR. Enter in data mode (grid) this field is a string 20 characters long Saw only when you try to restore a database from firebird.fbk (from odb). Reported error gbak utility. Only after that looked at data through the eyes. And saw.
You could enter characters as much as you want, but only 5 characters for a field, which is defined for 5 characters, are saved. Couldn't confirm the buggy behavior with a new created firebird-3-database. Note: Might be a problem with encoding, which has been changed from firebird-2.5-databases, used in LO 5.2.*, to firebird-3-databases. Only difference between firebird-3 and internal HSQLDB: With internal HSQLDB an error appears: "Value too long" when typing more than 5 characters in a field, which is limited to 5 characters. All tested with Version: 5.4.0.0.beta1 Build ID: 8672113ead4e403c55e31b1d9a3d1e0f3b299577 CPU threads: 4; OS: Linux 4.1; UI render: default; VCL: kde4; Locale: de-DE (de_DE.UTF-8); Calc: group
The base was created in LO 5.4.0 beta1. So the base 3.0. What remains is not 5 characters, but 20 characters can be seen in the data editor in LO (I recorded, came out of LO and re-entered). In addition, when i try to restore a database from firebird.fbk with utility gbak (firebird 3.0.2), an error is generated to the mismatch of actual length data and length fields. In any case, I wanted to help the project. If you think everything is fine then I'm happy.
Hmm, this has already been reported (or something very similar) and seems to be related to UTF-8 handling (from memory, as I recall).
Hmm, actually seems more like a duplicate of Robert's earlier reported bug 105711 *** This bug has been marked as a duplicate of bug 105711 ***
It should be noted that in my case the field length is not changed automatically. So for a FB database file is incorrect. Lengths remains equal to 5. If for example to increase it to 7 then when you try to view will be issued an internal error firebird_sdbc (string right truncation) and the data are not displayed.
Have tested this again. Isn't a duplicate of bug 105711. You could now create fields with a length of 5 characters, but could write 20 ASCII-characters into this fields. With special characters there will appear special problems. See bug 104956. All tested with a new created Firebird database and LO 6.3.4.2 on OpenSUSE 15.1 64bit rpm Linux.
*** Bug 129556 has been marked as a duplicate of this bug. ***
This seem solved with: Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 5d7251c7121cee8885fa9f2387c4a0625dd4ecee CPU threads: 4; OS: Windows 10.0 Build 21376; UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL
Could you give a try with LO 7.2.4 and brand new odb file? (so you must enable experimental feature to have the option to create a Firebird embedded odb). If you still reproduce this, could you attach the odb file?
Tested with a new created Firebird database under LO 7.3.0.1. with OpenSUSE 15.3 Couldn't insert more than 5 characters in a field for 5 characters any more. An error will appear: firebird_sdbc error: *arithmetic exception, numeric overflow, or string truncation *string right truncation *expected length 5, actual 6. Last version, which produces this bug in new created databases, has been here LO 7.1.5.2. Seems it has nothing to do with the changing of the character-set to UTF8. Something else must have been changed so it will work since LO 7.2.0.4 and all newer version for new created Firebird databases. If you open such a database in older LO-versions the bug will be there again. I will set this one to WORKSFORME. Feel free to reopen if you could reproduce it with a new created database
I checked for LO 7.2.4.1. It was not possible to enter more than 5 characters (Russian and Latin characters were entered). A non-localized message was issued :( a message about exceeding the length. The Gbak utility restores the database without errors.