Re: [libreoffice-users] Base questions

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 
between. 

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 :
> hsqldb:file:d:/somedir/mybase/basetest;default_schema=true;shutdown=true;hsqldb.default_table_type=cached;get_column_name=false
>      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: users+unsubscribe@global.libreoffice.org
> Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/global/users/
> All messages sent to this list will be publicly archived and cannot be deleted


-- 
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted