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

Hi :)
Yes, quite.  So 2 different front-ends (such as Base on different
machines or for different purposes) could use the same back-end.

"Daisy chaining" one to another seems like a really bad plan.

Fairy lights on Xmas trees used to be daisy-chained which meant that
if 1 bulb went out then they all did. That made it extremely difficult
to find out which one (or more) was the problem.  Nowadays most Xmas
tree lights are done in parallel so that each bulb is independent of
all the others.  Now if one or more bulbs go the rest bravely shine on
and it's easy to see which need replacing.

Having a string of databases all depending on the all the rest to work
properly sounds like a nightmare!

On the other hand there is a lot of sense in a modular approach with
specific discrete chunks doing specific jobs.  Base and Access each
have different modules within them.  So that building a Form or Report
straight from a Table makes it all quite inflexible and liable to
problems later on.  So it's generally better to build Queries, even if
the Query doesn't actually do anything except pass everything straight
through.  Then in future years the table could change quite radically
without forcing all the Forms and Reports to have to be redesigned.
Just edit the Query a little so that all the Forms and Reports
continue to get all get the inputs they are expecting.

It's something that makes Base much more highly scalable than Access.
Move the back-end tables from one program to another, either to get it
smaller and lighter or to deal with a greater weight of data.  perhaps
move the back-end from a stand-alone machine onto a network or up onto
a Cloud or some other place that might not even be envisaged possible
during initial design of the database program.

Even better is when Writer or Calc is used for the Forms and Reports
so that those things can be viewed by wide-eyed-end-users with no
training or understanding of database design.  They just get usable
output in a familiar setting and can edit around it themselves if they
need to change font-size or formatting or write a new letter based on
the old one.

Regards from
Tom :)

On 11 March 2014 12:23, jomali <> wrote:
On Mon, Mar 10, 2014 at 9:23 PM, Mark LaPierre <> wrote:

Hey Alex,

So what you are saying is that I can create a LO Base DB that references
tables stored in the standalone HSQLDB database with the JDBC connector,
and use that .odb file as a back end to another LO Base DB which acts as
a front end?  I've read, and been told on this mail list that LO Base
can't do that.  If I could do that I wouldn't need the standalone
HSQLDB, just a plain .odb file with some tables in it.

I've been trying to get this set up for months with no success.  I could
have done all this and more with Microsoft Access in just a few days.
This really shouldn't be this hard.

I think I need someone to hold my hand through the creation of just one
very simple LO Base DB with just two tables in it.


I think your confusion lies in equating an .odb file with an Access
database. The .odb file never contains the data. It is a sort of registry
that points to wherever the data is. Thus, Base is the front end, a real
database is the back end, and the .odb file serves as the intermediary (to


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.