7.2.0.1 7/28/21 daily build [really 7.2.0.1 RC1 to date] Windows 10 pro, 64 bit, 21H1 firebird_sdbc error: *arithmetic exception, numeric overflow, or string truncation *string right truncation *expected length 30, actual 35 *gds_$send failed *Exiting before completion due to errors caused by 'isc_service_query' Have several odb files created with 7.0 and 7.1 that can be opened and edited in 7.1.5.2. A small one = .99 mg works in 7.2. Two larger ones, 28.3 mg and 5.71 mg, I get the above error. I sometimes use Zorin 16 linux. When 7.2.0.1 RC1 was released I installed it and tried to open the 28.3 file and got the above error. Back in February 2021 I did find this error mentioned and the statement that a new system would be available to fix it.
Would it be possible to have an example file? Since attachments are public, attach a file with no private/confidential part or sanitize it with 7.0 or 7.1 LO version (see https://wiki.documentfoundation.org/QA/Bugzilla/Sanitizing_Files_Before_Submission)
*string right truncation *expected length 30, actual 35 The error appears to be text field strings in excess of the specified field length in the table master file. 7.0 & 7.1 are forgiving in uploading and file opening, 7.2 is not. To fix, use the Calc LEN function in calc to calculate the string length of each text field. Open the odf file in 7.1 and correct the specified text field string lengths, for each text field as appropriate. The odf file should then open in 7.2.
[Automated Action] NeedInfo-To-Unconfirmed
I'm not sure there's a bug here. Was it expected LO accepts a string with a length superior to the definition? I mean, would Firebird client would have accepted this?
Brant: I had forgotten about your email so I'm copying/pasting here so everyone have the information: " If 7.2 is not made more forgiving to text field string lengths in excess of the amount specified in the odb table master file, then users will have to make sure that specified string length for each text field is at least equal to the maximum length in the table for that field. Exporting to a calc spreadsheet, copying the field headings out to the right, using the LEN and Max functions and then updating the odb master file using 7.1 [upload file format length importing into 7.2] appears to solve the problem. The error I posted showed the master file specified 30 but base 7.2 found a string length of 35. I found 10 specified and a 12 maximum field length and 20 specified and a 28 maximum. Each text field has to be corrected. I know that I was lazy in that I used the auto feature for 10/100/1000 rows with an upload of 31,000 rows. In 7.0 and 7.1 that was not a problem, a file upload with with string lengths in excess of the specified amount would upload/open and it does not appear to have truncated the data. "
What about changing the structure of the table so it'll accept more than 30 characters?
(In reply to Julien Nabet from comment #6) > What about changing the structure of the table so it'll accept more than 30 > characters? Setting to needinfo.
This problem could only be solved by opening the database with an older version of LO like LO 7.1. The length of the field has been calculated wrong in older versions of Firebird internal database. See bug 108082
(In reply to Robert Großkopf from comment #8) > This problem could only be solved by opening the database with an older > version of LO like LO 7.1. > > The length of the field has been calculated wrong in older versions of > Firebird internal database. See bug 108082 But can the database be fixed in any way?
(In reply to Buovjaga from comment #9) > > But can the database be fixed in any way? The database has to be opened with LO 7.1 or an older version of LO. There must be a field, which is defined with length 30, but contains 35 characters. 1. A query like SELECT * FROM "Table" WHERE CHAR_LENGTH("Text") > 30 should show this field. The value must be changed. 2. other solution Table must be edited. Looking for the field, which is set to 30 characters and change it to 35 characters. After this changes you could open the database also in LO 7.2 an newer versions.
Thanks a lot. Then I think we can close this. It is unfortunate that this glitch existed, but good to know the db can be fixed.