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


Hi

OK, let me go back to square 1.

First of all I am not talking about a situation in which LibreOffice base needs to access data tables in separate files that use different database structures, e.g. one table is in MySQL and another is in PostgreSQL. This may be something that others need and I seem to recall that M$ access could do this but I do not need to.

Next, terminology because "database" can mean a number of things. Please correct me if I am wrong here. The data are contained in tables. These can be simple tables such as CSV tables or more complex tables constructed according to the rules of a particular database application. These tables can be in separate files or they may be embedded along with other information.

Then there are such things as queries, forms, reports and configurations which could, I guess, be each in separate files but are normally saved embedded together or with, say a data table. The results of running these, if saved, will be data tables or reports in separate files.

Finally there is the database application which may be in one or many files.

Now, to my situation. First of all I am using Debian GNU/Linux testing distribution. I use LibreOffice and for my database needs I use base. I use the built in HSQLDB database application and have my data tables embedded in the .odb file.

This has worked adequately (clunkily I would say, but I will keep other difficulties out of this discussion). However, base has recently become unusably slow in response to something that has changed in openjdk (I have asked about this elsewhere).

This has prompted me to revisit the question of whether to separate out my data tables. I am wondering whether it might be a workaround for the slowness problem. Also there may be advantages in backing up data separately and having it less vulnerable to anything going wrong in LibreOffice.

My data consist of a list of names, addresses etc. in one table and then some other tables that have additional information that only applies to (overlapping) subsets of the people in the names etc. table.

Way back in the past I used M$ access to handle these data. At that time my data tables were each in a separate file and everything worked very well.

When I moved over to OpenOffice.org I found that this was no longer possible. In order to run queries using data from different tables (all using the same database structure) I found I needed to embed all the tables into the same .odb files.

So my question is, is this still the same in LibreOffice?

More specifically, is it possible only using base, i.e. without running a separate database application, to access, run queries across and manipulate the data in data tables contained in separate files? I am assuming the these would probably be HSQLDB data tables.

If not, would it be possible if the data tables were embedded in the same file?

If either of these are possible then some pointers to how to separate out the data tables would be helpful.

Kind regards

John


--
For unsubscribe instructions e-mail to: users+help@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

Context


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.