LO / Firebird DB Integration

[Jean-Pierre Ledure]

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
>> file.
> 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 
bug.
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 
http://forum.openoffice.org/en/forum/viewtopic.php?f=83&t=61183
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.
Right.
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 ?

Thanks.

Jean-Pierre