Bug 168143 - Embedded Firebird databases are Firebird-version aren't portable (depend on firebird version)
Summary: Embedded Firebird databases are Firebird-version aren't portable (depend on f...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-08-27 17:37 UTC by Mike Kaganski
Modified: 2025-08-31 09:18 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2025-08-27 17:37:08 UTC
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.
Comment 1 Robert Großkopf 2025-08-28 05:59:17 UTC
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
Comment 2 Mike Kaganski 2025-08-28 07:46:59 UTC
(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.
Comment 3 Mike Kaganski 2025-08-28 07:51:45 UTC
(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.
Comment 4 Mike Kaganski 2025-08-28 11:08:34 UTC
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
Comment 5 mc 2025-08-29 04:43:51 UTC
Now *default* installation of Debian 13 (Trixie) install LO 25.2 and Firebird 4.0.5
In Windows 11 also with LO 25.8 are Firebird 3.0.7
In BSD not availabe sdbc driver !

This cause that .odb files aren't cross-platform, a real shame!
Comment 6 Robert Großkopf 2025-08-31 06:55:55 UTC
Have tested this again:
Uninstalled all the stuff, which has been installed by the Linux distrivution for Firebird and for LibreOffice.
Installed the original packages from LibreOffice, not the packages from the distribution.
There will be installed no Firebird package from the distribution (here OpenSUSE). Firebird of installed 
Version: 25.8.0.4 (X86_64)
Build ID: 48f00303701489684e67c38c28aff00cd5929e67
CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb)
Locale: de-DE (de_DE.UTF-8); UI: de-DE
Calc: threaded
runs without any problem.

The problem only exist with the packages Linux distributions will create, not with packages of LO.

Don't have any Ubuntu-version installed here, which installes Firebird 4 together with LibreOffice (since 2025) and set this dependency for the internal Firebird database of LibreOffice. So I couldn't test removing this version of LibreOffice and also Firebird on such a system and installing the original of LibreOffice.org

When I see
https://www.firebirdsql.org/en/firebird-5-0/
and the discussion in other bugs I don't know to which version we have to change: The version Ubuntu/Debian will decide to use since 2025 or the newer version Firebird 5.
We should better be independent from a special Linux distribution.
Comment 7 Rene Engelhard 2025-08-31 07:45:53 UTC
Hi,

> Have tested this again:
[...]
> The problem only exist with the packages Linux distributions will create, not
> with packages of LO.

That "test" doesn't show anything really new. It shows LO Base "can be used" (and you didn't even say which odb you used here...)

FWIW: It is the same mess as why LibreOffice didn't upgrade hsqldb (and why I said in the IRC log pasted above I ship https://packages.debian.org/search?keywords=libhsqldb1.8.0-java). 

I can't with firebird3.0 though since it's out of my control and could conflict at places...
 
> The version Ubuntu/Debian will decide to use since 2025 or the newer
> version Firebird 5.

That is indeed the question.
Even Debian unstable doesn't contain 5.0 yet :/

And 4.0 (as said above) was forced upon me quite late in the release cycle in January...
I feared this problem but then again also hoped that LO will upgrade firebird somewhen...

> We should better be independent from a special Linux distribution.

Ideally not, yes. 

But one problem also is why LibreOffice uses an old firebird.

Regardless, LO needs to update their internal copy anyway. If it's 4.0 it
probably restores compatibility as Mike already said in his first post correctly.

But then we'll get the same problem 4.0->5.0, as Mike also correctly said.

I always thought firebird was a bad decision and one should have used something which is known to be cross-architecture/cross-platform/cross-version compatible. But I think everyone assumed that using the backup format was exactly that which aparently is not - as this 3.0->4.0 upgrade showed vividly.
Comment 8 Rene Engelhard 2025-08-31 09:18:15 UTC
> > _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

see

e.g.
https://sources.debian.org/src/firebird3.0/3.0.12.ds7-13/debian/patches/upstream/riscv64-support.patch
https://sources.debian.org/src/firebird3.0/3.0.12.ds7-13/debian/patches/upstream/loongarch.patch

(and yes, riscv64 is a Debian release arch and libreoffice available for it - though with a big warning for Calc - and loong64 is in ports and probably will become one).