Base questions

users
#21

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.

In this way, the database (I assume) could easily be copied and re-attached either 'internally' or 'externally'.

Am I missing something here?

Thanks
Paul

#22

https://forum.openoffice.org/en/forum/viewtopic.php?t=54254

and the tutorial referred to in this post available from the same
OpenOffice.org forum.

Alex

#23

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

Alex

#24

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
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?

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?

Dave,

#25

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.

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.

#26

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.

I wouldn't consider MySQL and its descendents as good references for
data integrity.

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.

That would only confuse most end users.

The point is that the developers should make the most reasonable
choice - Which is imho obviously to use exclusively an external
client-server RDBMS.

And since the driver for PostgreSQL already comes with LO that's the
best choice. PostgreSQL is legendary for its robustness. Besides
shipping with a reasonable default configuration for "home" use and
being perfectly scalable up to a multi-master cluster of mainframes.

The developers should rather focus their limited resources on fixing
bugs with the Base client side (forms, reports, etc.).

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.

With PgAdmin (which comes with PostgreSQL) it's as simple as creating a
new document with LO.

Sincerely,

Wolfgang

#27

As I recall, at the time of the release of OpenOffice2, it had to be
like Access

Braindead.

- but of course, as Sun was mainly running the show, that
meant that it had to be multi-OS, thus Java based

Bullshit. There are plenty of cross-platform RDBMSes that are not
implemented in this grotesque proprietary abomination that Java is.

and a fairly "simple", "drop-in" piece of code with an appropriate
licence. One would do well to remember that at the time, the internal
Sun Base development team only comprised about 3 members of staff
working full-time on the project, thus resources were painfully
limited.

Just yet another argument in favor of just providing a driver for a
client-server RDBMS.

Sincerely,

Wolfgang

#28

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.

#29

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

That would only confuse most end users.

Hear, hear.

The point is that the developers should make the most reasonable
choice

This mindset will not help LO broaden its user base. Users (even if most
are apparently deemed stupid by some) should be in the driving seat and
not some anonymous "developers".

Pip Coburn writes this about the tech industry: "I believe that users
are always in charge and that supply is a necessary but not sufficient
condition for commercial success. Companies and products geared toward
this holistic user orientation will succeed at far greater rates than
those stuck in a supplier-oriented mind-set." As far as I'm concerned
that hits the nail squarely on the head.

And as to confusing users with complex choices... a well-designed system
can be simple for simple needs and complex for complex needs.

One-size-fits-all rarely fits anyone.

IMHO etc.

Jon

#30

Hi :slight_smile:
+1

I think Base nearly does do the best way around. The only problem is that
the easiest thing, the embedded database, is currently dangerously broken.
The devs appear to be addressing that although, obviously, they can't fix
the whole thing all at one go. The first step seems reasonably well chosen
to get the main bulk away from java.

I'm sure Java didn't used to be so awful. It seems to have nose-dived
since Oracle took over but maybe that is preparation for monetising it and
that is a reasonable thing for a profit-making company to want to do.

It's like the story of the scorpion and the fox crossing a river. The
scorpion stings the fox and as they both sink the fox asks why. The
scorpion replies that it's his nature to sting and he can't help it. So
can we really blame a profit-making company from attempting to subvert a
free product it owns in order to later be able to sell an "enterprise" or
"professional" version?

It's a shame openJava can't escape and gather a huge community as
LibreOffice did back when OpenOffice was owned by Oracle.

Base currently allows users to start of by using an internal back-end and
then move it to an external tool when they are ready. [shrugs] Seems a
good plan to me.
Regards from
Tom :slight_smile:

#31

I think Base nearly does do the best way around. The only problem is that
the easiest thing, the embedded database, is currently dangerously broken.
The devs appear to be addressing that although, obviously, they can't fix
the whole thing all at one go. The first step seems reasonably well chosen
to get the main bulk away from java.

I'm sure Java didn't used to be so awful. It seems to have nose-dived
since Oracle took over but maybe that is preparation for monetising it and
that is a reasonable thing for a profit-making company to want to do.

My criticism was not at all directed specifically against Base as I
don't know the first thing about it. It was rather directed against the
idea that developers know better than users. They rarely, if ever, do,
IMHO.

Users have a zillion creative ways of (mis-)using a product, many of
them undreamt-of by its developers. So the more user choice and less
developer diktat a product exhibits, the better it is, in general.

I avoid Java as much as I possibly can (read: always) but my argument
has nothing whatsoever to do with Java.

Jon

#32

On 2014-08-05 06:02:12, Wolfgang Keller wrote:

> As I recall, at the time of the release of OpenOffice2, it had to
be
> like Access

Braindead.

> - but of course, as Sun was mainly running the show, that
> meant that it had to be multi-OS, thus Java based

Bullshit. There are plenty of cross-platform RDBMSes that are not
implemented in this grotesque proprietary abomination that Java is.

> and a fairly "simple", "drop-in" piece of code with an appropriate
> licence. One would do well to remember that at the time, the
internal
> Sun Base development team only comprised about 3 members of staff
> working full-time on the project, thus resources were painfully
> limited.

Just yet another argument in favor of just providing a driver for a
client-server RDBMS.

Sincerely,

Wolfgang

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

--
william w. austin airedad@att.net
"life is just another phase i'm going through. this time, anyway ..."

#33

My comment, or Sun's decision ?
How many of those cross-platform RDBMs were :

- available in 2004 (when the decision was made to upgrade the OOo1 Base
iteration to something new) ?

- didn't require masses of developer investment time and resources to
integrate into the codebase ?

- ran on OSX, Windows and Linux ?

- weren't Java based ?

- could be made to run in a single file and be portable across various
OSes ?

Personally, I always regretted the demise of the way database
functionality was set up in OOo1.

Alex

#34

Hi :slight_smile:
I was kinda agreeing with you, hence the +1. I think people kinda
understood what you meant and i suspect other people agree with you too.
The devs sometimes have great plans and good ideas and then users do some
crazy things. It's difficult to anticipate what users will find difficult
and what is going to be easier for them to understand.

I've really enjoyed this thread. Some amusing and enlightening posts.
Thanks and regards from

#35

The weird thing is that Java is havely used in the Oracle databases. How com they can have quite reliable databases...

#36

> Bullshit. There are plenty of cross-platform RDBMSes that are not
> implemented in this grotesque proprietary abomination that Java is.

My comment, or Sun's decision ?

Sun's decision. Compulsive Javamania.

There are bulkloads of programming languages and frameworks that allow
cross-platform application development way better than Java will ever
do.

How many of those cross-platform RDBMs were :

- available in 2004 (when the decision was made to upgrade the OOo1
Base iteration to something new) ?

Postgres (back then without SQL) version 1 was released in 1989.

And before Postgres there was Ingres from the same developers. That's
where the name comes from, after all.

- didn't require masses of developer investment time and resources to
integrate into the codebase ?

The SDBC driver was already there, developed by third-parties.

- ran on OSX, Windows and Linux ?

PostgreSQL runs on:

http://en.wikipedia.org/wiki/PostgreSQL#Platforms

It's even *shipped* with the default installation of MacOS X Server.

- weren't Java based ?

PostgreSQL isn't.

If you're a completely obsessive Java fetishist, you *can* use PL/Java
for server-side application logic though.

- could be made to run in a single file and be portable across various
OSes ?

I don't see a reason for the "single file" requirement.

It's installed separately anyway.

Sincerely,

Wolfgang

#37

I know that its not LO base specific but can,t find a way how to or
example of something like this.
What i want using cars as example is to make a search for
color,year,doors,model.kilometers driven,cabrio,engine,fuel and so
many more options.
Who can help me on my way how to set somthing like this up ?

Just RTFM. >;->

For Base, the manual is at:

https://wiki.documentfoundation.org/images/e/e8/BH40-BaseHandbook.pdf

For relational databases in general, the DB-Main tutorial is pretty
good imho:

http://tinyurl.com/mrab534
http://tinyurl.com/md84k87

Or just google for a few keywords:

http://tinyurl.com/pqdebuj

Sincerely,

Wolfgang

#38

Hi :slight_smile:
An rtfm answer that DOES link to documentation is still a bit rude but i
like this one. It's the links that make it really useful.

Do these links go to the same place?
https://wiki.documentfoundation.org/Documentation/Publications#LibreOffice_Base_Handbook
https://wiki.documentfoundation.org/Faq

Regards from
Tom :slight_smile:

#39

http://www.openoffice.org/dba/drivers/postgresql/

shows the limitations of the driver at the time the decision to move to
hsqldb was made, and they were quite severe. In addition, it didn't
build on OSX (having tried it myself) at that time (or even for a long
time afterwards, in fact not until Lionel tidied up the code within the
LibreOffice project).

Anyway, all moot now.

Alex

#40

So, what appears to be happening is consensus that other database back-ends should be used.

What is implied, is that Base does not have the ability to generate from a package, the selected external database of choice.

1. Is this correct?
2. Should it be corrected?
3. When generated, should 'internal' mean in the same folder, 'external' mean somewhere else?

Thanks
Paul