Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index

Op 4 aug. 2014, om 20:23 heeft Jean-Francois Nifenecker het volgende geschreven:

Le 04/08/2014 18:59, dave boland a écrit :

I'm getting a little confused.  My understanding is that there are
really two issues here.  One is that LO Base is RAM resident - all
updates are held in RAM until saved by the user, or the program is
closed.  Correct?  If so, this situation will expose the user to data
loss between saves.  

There are two components here: the DB engine (eg HSQLDB) and the
front-end (ie LO-Base).
In embedded mode, running Base stats the DB engine and opens the wanted
database. In this situation, yes, database updates are set to ram until
the database is saved, either voluntarily or when Base is shut down.

And yes, any flaw in *any* piece of software running while Base and the
DB also run, can create DB loss.

It is important to separate "embedded" and "incore". They are completely different things.
The important thing is that embedded means that the dbms is not independent of the application... 
That said, the db crashes when the app crashes and vice versa.

So, if a database runs 'as a service', listening to any incoming requests and serving them, then 
the database is separate. Yes, of course it can crash, but it should be impossible for the user or 
application to be the cause. 

Generally, for any dbms it should be top priority to keep data consistent. A dbms should be crash 
resistant, in that a transaction either is committed or is not, and not in any bogus state in 

In core, on the other hand means that (part of) the data is kept in core. That does not mean the db 
is not crash resistant, though.
Oracle incore database (used to be "Times Ten" and now an option) does keep the data in core, but 
saves all change actions in a redo-log. Upon restarting after a crash the redo-log is executed so 
the database is back in the latest committed state. The same process is used for backup procedures.
So, in that case one has the speed of incore, while the persistency of disk based. 

The other issue is that LO Base uses an embedded database, which means
that the data files and the GUI, reports, etc. are combined into one
file that can be corrupted.  The suggestion is to use a split system
where the data files are separate from the other files.  Correct?  If
so, at best, the data may be a little safer, but forms, queries, etc.
can still be corrupted.

Yes, this is what "split-mode" is all about.

A database like MySQL and mariadb cache the updates and then write them
to disk every 1/2 to full second (or however configured).  Seems like a
good idea.

So I come back to my suggestion earlier today - LO Base needs to give
the user the opportunity to specify what they want - RAM or file based,
single file or multiple files.  Would that be difficult to do?

WRT HSQL it's just a couple settings away:

(1) in LO global settings (Tools/Options, Advanced page) specify where
the external HSQLDB engine is stored (Class Path button)
  -> Add archive: points to the hsqldb.jar
  -> Add Folder: points to the directory where hsqldb.jar is stored
(lib dir)

  Then make sure to check the test button

  These setings are stored in the user profile /config directory.

(2) in Base, DB creation wizard
  -> at step 1 : select JDBC database
  -> at step 2 : specify the DB address settings
     Datasource URL :
     JDBC Driver class: org.hsqldb.jdbcDriver

  Test with the Test Class button.

  These settings are stored in the RegistryModifications.xcu file.

To me, the main difficulty lies in the backup of these settings (config
dir and RegistryModifications.xcu and the .odb file), so that you may
change PC without hassle. Unless I'm missing the obvious, it is not the
case currently.

Jean-Francois Nifenecker, Bordeaux

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.