https://ask.libreoffice.org/t/isc-service-query-can-not-connect-to-my-lo-base-firebird-data-anymore/125893/ Create an Firebird embedded ODB on Windows. Open and save it in LibreOffice (same version!) on Linux, where system Firebird is version 4 or higher. Try to open it again on Windows. Since our bundled FB is v.3, and on Linux, the system version is used (including gbak), we have a problem here. The saving using a newer FB version has upgraded the database data in our package - and now we can't use it on Windows. If there were a way to use embedded FB on Linux, we would need to do that, even when there is system FB available - just because of this. And of course, upgrading our bundled FB is badly needed; and yes it will break backward compatibility of the ODBs, for the same reason.
Seems this problem only exist for a system, where Firebird 4 server has been installed. I have installed Firebird 3 server (OpenSuSE 15.6) and will get no problem to work with internal Firebird databases. There are people (with Linux), who reported the same buggy behavior, which is described here: A database I created here with internal Firebird gives errors and couldn't be opened under other systems, because the user had installed Firebird 4 server also. But: Internal databases should be independent from an external installed server. Also external connection to a Firebird file should work independent from installed Firebird server. But it won't - see bug 159155
(In reply to Robert Großkopf from comment #1) > Also external connection to a Firebird file should work independent from > installed Firebird server. But it won't - see bug 159155 Totally unrelated - and NOTABUG (as I wrote there, the database files, DY DESIGN if FB, are system-dependent, so unportable; only backup format is portable - which we therefore are using in our ODBs). The problem here is, that though backup format is portable in a sense that it can be moved to another system and open using the same or newer version of FB, it is versioned - so a newer version of FB will write it back in the format, that can't be read by the original version; so the fact that we depend on the system FB is problematic. However: as far as I remember, FB does *not* provide an "embedded" solution for Linux *at all* (maybe that changed in v4 or v5?). So the "should" could be just wishful thinking.
(In reply to Mike Kaganski from comment #2) > However: as far as I remember, FB does *not* provide an "embedded" solution > for Linux *at all* (maybe that changed in v4 or v5?). So the "should" could > be just wishful thinking. No I was wrong; it is libfbembed on Linux. So - it's a valid expectation, to use embedded version on Linux, too.
From IRC: > _rene_: mikekaganski: the problem is thst people forced othe people to use 4.0.. i saud thst to our firebird maintainer back then... > _rene_: mikekaganski: and that lo relues on an old version. but that problem will maybe exist on 4.0 vs. 5.0 too :/ > mikekaganski: _rene_: my question is: what could be a problem, if we always bundle our own build of FB embedded .so, irrespective of the system FB? > _rene_: for hsqldb i keep hsqldb1.8.0 around fir infinity for this reason, but i am nit the firebird maintainer... > _rene_: mikekaganski: that it's a bundlee version and that should be avoided in principle if posdible > _rene_: and then there is the problem of srchitecture support > mikekaganski: _rene_: the "if possible" is the problem :-) I understan why it is undesirable in general; my question is about a specific situation, that has its root in how FB handles its file versions > _rene_: are you going to fix any arch? by using it from the systfm you relay that to firebird ;) > _rene_: https://buildd.debian.org/status/package.php?p=libreoffice. ignore mios64el and i am not sure about s390x > _rene_: but loong64 will come sooner or later > mikekaganski sees the last argument, it's really critical > noel_grandin: maybe just disable firebird if the system version is wrong? > _rene_: besides that the white ones need to work (or firebird disabled...) > _rene_: and have no internal db at all? > _rene_: there is archs where hsqldb is disabled too > _rene_: because java is disabled bevause either not ecisting or broken > _rene_: of the archs above, only a subset has java support > _rene_: ure-java | 4:25.8.0-1 | unstable | amd64, arm64, i386, riscv64 > _rene_: mikekaganski: this is a mess. i'd have preferrred out firebird mainer keeping a 3.0 -dev, but he didn't > _rene_: and libfbembed2 from 4.0 needs 4.0-server-core > _rene_: so i was forced to built agaimst 4.0 without resorting to the internal one :/ > _rene_: *if* one forces internal fb > _rene_: we need a --disable/--without switch. then people might get no internal db tbough. no hsqldb, no fb > _rene_: :-( > _rene_: mikekaganski: ftr, https://lists.debian.org/debian-release/2025/01/thrd2.html. look for firebird