Description: Pre-existing Base db with Firebird Embedded that worked well under LibreOffice 7.1. Can not open/edit queries or tables in the db. "The connection to the data source "ACCOUNTS - Copy" could not be established. firebird_sdbc error: *arithmetic exception, numeric overflow, or string truncation *string right truncation *expected length 20, actual 25 *gds_$send failed *Exiting before completion due to errors caused by 'isc_service_query' Steps to Reproduce: 1.Uninstalled 7.2 2.Re-installed 7.1.5.2 3.Reviewed Tables and Queries. Nothing found Actual Results: The connection to the data source "ACCOUNTS - Copy" could not be established. firebird_sdbc error: *arithmetic exception, numeric overflow, or string truncation *string right truncation *expected length 20, actual 25 *gds_$send failed *Exiting before completion due to errors caused by 'isc_service_query' Expected Results: Open useful database with no errors Reproducible: Always User Profile Reset: No Additional Info: No other information
Please test with a clean profile, Menu/Help/Restart in Safe Mode
(In reply to m.a.riosv from comment #1) > Please test with a clean profile, Menu/Help/Restart in Safe Mode Sorry. I should have added that I did test with a clean profile in Safe Mode. I received the same results.
[Automated Action] NeedInfo-To-Unconfirmed
Seems duplicate of bug 144172 (that has more details).
Found a table with 1 field set to a length 20 but the actual entries exceeded lengths of 20.
Surely, it is a bug if you have a field with a defined character limit of 20 and the software application nonetheless allows you to store more than 20 characters, and then subsequently screws up restituting that character string (or value) ? I would argue that this is buggy behaviour. Rings a bell though, as an already existing bug...
Inf act, it sounds very similar to, or is a DUPLICATE of, bug 104956
(In reply to Alex Thurgood from comment #7) > Inf act, it sounds very similar to, or is a DUPLICATE of, bug 104956 Bug 104956 was reported for fields, which would save less tan the 20 characters, but length of 20 characters has been defined. An example file would be helpful: database with one table - more than the allowed length saved in the table.
(In reply to Alex Thurgood from comment #6) > Surely, it is a bug if you have a field with a defined character limit of 20 > and the software application nonetheless allows you to store more than 20 > characters, and then subsequently screws up restituting that character > string (or value) ? > > I would argue that this is buggy behaviour. > > Rings a bell though, as an already existing bug... Surely, it is a bug that is still there in release 7.2.1.2
Created attachment 175526 [details] Buggy table created with version 7.1
Obviously a bug is fixed in version 7.2 In 7.1 it is possible to enter more characters than defined (see example). This buggy table can't be opened in version 7.2. I have no suggestion, how to solve the problem by software. A program should not change content. It is annoying, but I would prefer to correct the column content manually with an older version.
Could confirm the buggy behavior with the attached database. The file could be opened in LO 7.1.5.2 under OpenSUSE 15.2 64bit rpm Linux without any problems. The table has been defined for filed "Column 1" with VARCHAR(5) and for "Column 2" with VARCHAR(10). Having a look at the content, which could been saved in LO 7.1.5.2: "Column 1" has been added content with 9 characters, "Column 2" has been added content with 11 characters. When trying to open this file in LO 7.2.2.1 on the same system it fails. There comes a warning the content for the field is too long. The behavior in LO 7.1.5.2 had been wrong. So I don't know how there could be fixed anything …
To be compatible to version 7.1 version 7.2 should adapt the definition of the field length to the actual length. Changing a definition automatically seems less critical to me than changing content. Users can be informed about the issue with a dialog. Then they can correct content or field length, whatever is more important individually. The database could be used anyway. And: No, I don't have time to implement this suggestion.
*** Bug 145899 has been marked as a duplicate of this bug. ***
(In reply to Wolfgang Hördt from comment #13) > To be compatible to version 7.1 version 7.2 should adapt the definition of > the field length to the actual length. > Changing a definition automatically seems less critical to me than changing > content. > Users can be informed about the issue with a dialog. > Then they can correct content or field length, whatever is more important > individually. > The database could be used anyway. > > And: No, I don't have time to implement this suggestion. LO fails during connection to the database in Connection::construct, it detects it's an embedded Firebird which uses old fdb file so tries to run runBackupService. This one fails and so LO doesn't even go to isc_attach_database in order to connect to the database. See https://opengrok.libreoffice.org/xref/core/connectivity/source/drivers/firebird/Connection.cxx?r=4761e11a#302 The result is we can't even enter Tools/SQL to update system tables and so change definition of the table. In brief, I don't think it's possible to fix the file from recent LO. Now perhaps, the file may be fixed in older LO (see Robert's comment 12 about the presence of too long values) then migrated in recent LO. Have in mind that Firebird had been put as experimental feature because considered as not stable enough. IMHO this one should be considered as WONTFIX but if someone disagrees, don't hesitate to explain why and provide some hints to fix this.
(In reply to Julien Nabet from comment #15) > > IMHO this one should be considered as WONTFIX but if someone disagrees, > don't hesitate to explain why and provide some hints to fix this. Se it the same. We couldn't get back to a buggy behavior to get old created databases working. Installing an older version LO will solve this problem.
Lionel: after Robert's feedback, ok too for WONTFIX here?
(In reply to Robert Großkopf from comment #16) > We couldn't get back to a buggy behavior to get old created > databases working. Installing an older version LO will solve this problem. In principle, I disagree, Ascending compatibility of user data is of cardinal importance. OTOH, if nobody is going to fix this bug, then WONTFIX is more honest than letting the bug rot :-( Maybe "at least" document how to extract the fdb from the odb, fix it and put it back? (In reply to Julien Nabet from comment #17) > Lionel: after Robert's feedback, ok too for WONTFIX here? Could you first try to fallback to isc_attach_database when runBackupService fails? If that works (along with a pop-up warning?) it at least gives the user a chance to fix the issue manually? I guess the bug is more related to an upgrade of the Firebird version than LibreOffice code, so the "real fix" would be in Firebird; runBackupService should accept all data created by a past version of FireBird (!) Maybe we should open the subject of ascending data compatibility with the Firebird devs?
(In reply to Lionel Elie Mamane from comment #18) > ... > Could you first try to fallback to isc_attach_database when runBackupService > fails? If that works (along with a pop-up warning?) it at least gives the > user a chance to fix the issue manually? I commented the runBackupService in Connection::construct just to test and had this: warn:connectivity.firebird:223594:223594:connectivity/source/drivers/firebird/Util.cxx:57: firebird_sdbc error: *I/O error during "open" operation for file "/tmp/luiv08z.tmp/luiv092.tmp/firebird.fdb" *Error while trying to open file *No such file or directory caused by 'isc_attach_database'
(In reply to Julien Nabet from comment #19) > "/tmp/luiv08z.tmp/luiv092.tmp/firebird.fdb" > *Error while trying to open file > *No such file or directory Did you have a look at this folder? Could be the file isn't unpacked right form LO.
(In reply to Robert Großkopf from comment #20) > (In reply to Julien Nabet from comment #19) > > "/tmp/luiv08z.tmp/luiv092.tmp/firebird.fdb" > > *Error while trying to open file > > *No such file or directory > > Did you have a look at this folder? Could be the file isn't unpacked right > form LO. Yes it contains firebird.fbk but if I use: const OString sFirebirdURL2 = OUStringToOString(m_sFBKPath, RTL_TEXTENCODING_UTF8); and use for isc_attach_database, I got: warn:connectivity.firebird:226371:226371:connectivity/source/drivers/firebird/Util.cxx:57: firebird_sdbc error: *file /tmp/luln2ix.tmp/luln2j0.tmp/firebird.fbk is not a valid database caused by 'isc_attach_database'
(In reply to Julien Nabet from comment #21) > (In reply to Robert Großkopf from comment #20) > > (In reply to Julien Nabet from comment #19) > > > "/tmp/luiv08z.tmp/luiv092.tmp/firebird.fdb" > > > *Error while trying to open file > > > *No such file or directory > > > > Did you have a look at this folder? Could be the file isn't unpacked right > > form LO. > > Yes it contains firebird.fbk There has to be a firebird.fbk and a firebird.fdb in the same folder. The *.fbk is the file created by a backup, which is also the saved file inside the *.odb-file.
(In reply to Robert Großkopf from comment #22) > ... > There has to be a firebird.fbk and a firebird.fdb in the same folder. The > *.fbk is the file created by a backup, which is also the saved file inside > the *.odb-file. Sorry, I forgot to tell it contained only firebird.fbk file, no other file (standard or hidden). To be even more precise, here's what I got in /tmp/luln2iz.tmp ./luln2ix.tmp ./luln2ix.tmp/luln2iz.tmp ./luln2ix.tmp/luln2iz.tmp/fb_init ./luln2ix.tmp/luln2iy.tmp ./luln2ix.tmp/luln2j1.tmp ./luln2ix.tmp/luln2j1.tmp/firebird.fbk
Julien, you wrote in comment 15 that the odb bug reproduction file contains the "old way" fdb file, not the "new way" fbk file, or did I misunderstand? That is a key question, and the basis of my idea. My hope is that runBackupService chokes on that file, but the firebird engine does not. So you need to extract the .fdb file from the odb (like old LibreOffice was doing) and isc_attach_database to that.
(In reply to Lionel Elie Mamane from comment #24) > Julien, you wrote in comment 15 that the odb bug reproduction file contains > the "old way" fdb file, not the "new way" fbk file, or did I misunderstand? > That is a key question, and the basis of my idea. > > My hope is that runBackupService chokes on that file, but the firebird > engine does not. > > So you need to extract the .fdb file from the odb (like old LibreOffice was > doing) and isc_attach_database to that. It seems I had to be really confused since I mixed fbk and fdb. Here's the result of unzipping the odb file from Wolfgang's attachment (comment 10): unzip Test-db.zip Archive: Test-db.zip extracting: mimetype inflating: content.xml inflating: database/firebird.fbk creating: forms/ creating: Configurations2/ inflating: settings.xml creating: reports/ inflating: META-INF/manifest.xml So we got an fbk not an fdb. Then, runBackupService is called in connectivity/source/drivers/firebird/Connection.cxx: 300 if (m_bIsEmbedded && !bIsFdbStored) // We need to restore the .fbk first 301 { 302 runBackupService(isc_action_svc_restore); 303 } m_bIsEmbedded is true since it's an embedded Firebird. bIsFdbStored is false since there's no fdb in odb file (and so !bIsFdbStored is true and LO calls runBackupService) Very sorry about the confusion I brought :-(
(In reply to Julien Nabet from comment #25) > (In reply to Lionel Elie Mamane from comment #24) >> Julien, you wrote in comment 15 that the odb bug reproduction file contains >> the "old way" fdb file, not the "new way" fbk file, or did I misunderstand? >> That is a key question, and the basis of my idea. > > It seems I had to be really confused since I mixed fbk and fdb. > > Here's the result of unzipping the odb file from Wolfgang's attachment > (comment 10): > unzip Test-db.zip > Archive: Test-db.zip > inflating: database/firebird.fbk > So we got an fbk not an fdb. OK, then forget my idea. However, if you feel up to it, there is a conversation to be had with the firebird devs about backwards compatibility. Ideally, we would write to them something along the lines of: * this fbk file (send them just the fbk file), created with Firebird version XXXX (the one in LibreOffice 7.1) is accepted by runBackupService(isc_action_svc_restore) in Firebird version XXX , although it contains non-conforming data in that a row contains in column XXXX a value of length YYYY chars, but the row is contstrained to maximum ZZZZZ chars. * However, in Firebird version QQQQQ (the one in LibreOffice 7.2), this error * This lead to users not being able to access their data anymore. For reasons of backwards compatibility, would you consider making runBackupService(isc_action_svc_restore) more "be liberal in what it accepts", insofar as it will accept data produced by earlier versions of Firebird?
(In reply to Lionel Elie Mamane from comment #26) > ... > OK, then forget my idea. > > However, if you feel up to it, there is a conversation to be had with the > firebird devs about backwards compatibility. Ideally, we would write to them > something along the lines of: > ... Good idea! Done here: https://github.com/FirebirdSQL/firebird/issues/7091 Should we then consider this one as NOTOURBUG or it's a bit too early to tell?
Since we're dependent on upstream, let's put this one to NOTOURBUG.