LO / Firebird DB Integration
jp at ledure.be
Fri Jun 28 02:37:15 PDT 2013
1. Risk of data corruption with the embedded database
On 26/06/2013 13:55, Lionel Elie Mamane wrote:
>> AFAIK the main issue in using a HSQLDB database embedded in the .odb
>> file is that, when LO crashes, the chance is big that the database
>> is destroyed: the recovery process does not recover that part of the
> Oh. That's bad. I never encountered it, but I don't use embedded
> database much. If this is reproducible ...
Not easy to reproduce ! If I succeed, I promise, I will document it as a
Nevertheless it is real. I experienced it several times.
The root cause is more likely to be something like
> - The database itself is corrupted (e.g. the SQL file is only
> partially written, or the binary-format "CACHED" table file is
> corrupted, ...).
It never happened anymore after my decision to split the concerned
databases as explained a.o. in
I can guess from my findings on user forums that a lot of users have
adopted the same strategy: splitting front- (i.e. the logic: queries,
forms, macro's, ...) and backend (the data).
2. To embed or not to embed ?
> I do think that embedded database has a role to play in the "early
> life" of users; think e.g. of those just "graduating" from using a
> spreadsheet as a rudimentary database.
> Embedded database works like they expect it to, and then don't need to
> understand the difference between database and UI. I've found that
> this is a pretty big cognitive hurdle in the beginning.
I totally agree with your statement.
> And even for expert users, there are inherent advantages to embedded
> database. Essentially, their easy transportability. I can email one to
> another user for data entry and he emails it back to me.
Nevertheless consider next advantages of splitting back- and front-ends:
- Multiple users share the same data
- User interface can be modified without impact on data.
- Database can be upgraded without impact on design.
- Deployment of the front-end is easy
- Multiple developers can work on distinct front-ends
- Less data corruption risk as seen above
As a conclusion, might I suggest that a bit automation facilitating a
clear initial choice for a new database between embedding or not
embedding data could be appreciated by users ?
Not embedding would simply mean that data files shall be stored in the
same directory as the database document (.odb) and that the directory as
a whole should be considered as the database.
In my modest opinion, more appreciated than a technology change from
HSQLDB to Firebird ?
More information about the LibreOffice