On Mon, Aug 4, 2014, at 12:30 PM, Alexander Thurgood wrote:
Le 04/08/2014 16:41, Paul D. Mirowsky a écrit :
Before I begin, I will plead ignorance of how these things really happen.
It appears that what should be happening is that the database should
always be external, but whether it is placed inside the same folder.
To the user, the interpretation of 'internal' would be that it is within
it's own folder and 'external' would be that the actual database is
somewhere else during set-up.
The default Base file, with an ODB extension, is a container (zipped).
Within that container are files and subfolders, some files describe the
structure and content of the database in a form that LibreOffice's
embedded hsqldb engine can read when you load the file. The subfolders
generally relate to other aspects of the ODB file, such as macros,
forms, reports, report definitions (XML), query definitions, etc)
When you reference an outside db backend, everything but the actual
database content and data defintitions get stored in the ODB file, with
simply a reference to that content and how to access it being stored in
the ODB. In other words, your data is actually safe somewhere else (on a
server, on another part of your hard disk, etc)
Utimately, for as long your actual database data is somewhere else, you
could screw up your ODB file and still not affect your data. However,
you would potentially lose all of your query/report definitions, your
macros, forms, etc. Note that forms do not have to be stored within the
ODB, they can be stored as standalone documents. The same goes for
reports, although the report definitions are always stored within the
ODB file (unless someone has found a way to get around that).
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.
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.
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
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?
Yes, I know that you can link to other back-end db's, but LO Base
doesn't create those db's - that has to be done ahead of time by someone
that is skilled with the particular db. Correct?
http://www.fastmail.fm - Does exactly what it says on the tin
To unsubscribe e-mail to: firstname.lastname@example.org
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
[libreoffice-users] Re: Base questions · Alex Thurgood
Re: [libreoffice-users] Base questions · Rob Jasper
[libreoffice-users] Re: Base questions · Alexander Thurgood
Re: [libreoffice-users] Re: Base questions · Wolfgang Keller
- Re: [libreoffice-users] Base questions (continued)
Impressum (Legal Info)
: 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