Compatibility of LO Base with Access databases

users
#21

Hi Ian,

*Re: The LO Base discussion* - just my "Penny's Worth"!!!

The only way I got any (sort of results) was by using MySQL as the
backend but it took a couple of months to get it working and after a few
months even that crashed on me. I recently had to re-build my computer
after a hardware failure and my OpSys upgraded to 64bit and since then I
can not even get the MySQL linking in LO Base to even start!!

It it is fairly rare for people to suffer from catastrophic failures and
data loss using mysql - most of the time, it is usually possible to
salvage most, if not all of one's data providing one takes an interest
in the manuals on how to administer such a database server (and there
are a plethora of them, not least Oracle's own documentation).

So if you are happy to keep lots and lots of backups, and spend lots and
lots of time re-building everything at almost monthly intervals - and by
re-building I mean the Database Tables, redesign all your Forms and
set-up all your Queries and Reports from scratch - then go with it,
otherwise give it a miss.

It is also not strictly necessary to keep backups of the mysql database,
although it is indeed a recommended practice. Again, the documentation
is replete on how to do this safely.

From the interaction I've had with you on and off the list, I would say
that you have been unfortunate with regard to some of your expectations,
in that you did not wish to, or failed to, understand what it meant to
have a database server, and didn't wish to spend time understanding how
it worked in case things did go pear-shaped. I can understand this from
a user perspective, and in that case, choosing mysql as your backend
database engine was probably not a good idea, but as you found out for
yourself, neither was the embedded hsqldb.

My own experience with mysql databases has been rock solid in terms of
data integrity now for more than 10 years, including various different
types, from stock management, IP rights management, accounting, etc,
although I will admit that interaction with StarOffice, OpenOffice.org
and LibreOffice has caused some issues, but this mostly lies with
limitations or bugs within those programs and not mysql itself (barring
a few connector driver problems).

Fact of the matter is that databases when used with LO, embedded or not,
probably require more work than most "Access-users" are willing to put
in. There is no "simple", "out-of-the-box" solution for such users when
attempting to switch to LO, everything will be a compromise of sorts, be
it form design, reporting, stability, multi-user access, etc.

LOBase was always designed with the eye of a database administrator in
mind, and the attempted switch to a user-centric orientation just didn't
quite happen (for various reasons within Sun, and then Oracle). However,
what we have got is not bad as things go, providing that one can accept
its limitations (or alter one's work flow to work around them).

Alex

#22

Base and some of its limitations (including enbedded HSQLDB) are well
described here:
https://wiki.openoffice.org/wiki/FAQ_(Base)

The last two times I needed a multi user database accessible over the web I
went with a LAMP approach. The *upfront* set up and learning curve was
higher but *less* time is required over the life of the project
(development & maintenance) as these tools have exceptional stability and
performance, have very few bugs, excellent documentation and require no
client side maintenance. AND, it's far more rewarding developing the
application versus fighting the bugs and limitations of your tools ... as
often happens when using Access, Base and their like (been there, done
doing that).

#23

Hello,
I agree full-heartedly with Alex, but then I have been working with relational DBs
ever since my days at IBM (DB2), where I specialised on databases for a while. In fact
I happened to get to know one of the fathers of that technology - Chris Date. I have
been using OO and LO with a MySQL-backend for at least 10 years since switching from
Lotus (Dbase-based). Except for a couple of snags with the MySQL-connectors (native,
Java and ODBC) I have never had any problems worth mentioning, and - of course - I do
back up my DB. But then, I probably am not the average "end-user"-oriented bloke, even
though I would not call myself a DB-specialist any more. I use LO and MySQL for the
administrative side of a wind band, working "natively" with the underlying tables and
using a number of views based on joined tables for reporting. Using Drupal as the framework
for the homepage of the band (www.rainermusik.at) I also have integrated some of those
MySQL-views with Drupal.
I never really went into using LO-forms or Basic macros because I feel that one should take
the effort to use a framework such as Symfony for building more involved applications,
using an object-oriented approach, with something like Doctrine as a link between the
objects/methods of the application and the MySQL DB.
Regards from sunny Salzburg
Heinz

#24

For most individuals, dBase3 is adequate. Perhaps a little slow, but
with current hardware, not spectacularly so. However, the major
stumbling block is that there is even less LibO documentation for it,
than there is for Base.

jonathon

#25

I used dBase in the 80s and I must assume that since it still seems to have a demand, that users are still out there and happy with it. It did have some nice features, such as the programming capability, which is why I tried to import my files into LO rather than reinvent the wheel. I suspect most of the users are "on the other side of the pond", since I rarely hear of dBase users here in the US. Then again, Fortran is still active too. It takes a long time for that flywheel to coast to a stop.

Girvin

#26

dBase is still available, even an updated DOS version.

http://www.dbase.com/

#27

My doctors office uses a dBase based system for administration, keeping
patient records and so on. It has integrated LO for many purposes, i.e.
medical letters. As I was told, reading those dbf files using scripts is easy
(dbf_dump), modifying dbf files from outside the program however tedious,
they use LO base for that purpose. Unfortunately, the SQL commands for dBase
are limited.

Walther

etc.Am Donnerstag, 4. August 2016 schrieb Girvin Herr:

#28

dBase files are plain text, but they have a specific format, which varies with version (feature add-ins). I did some research on the file format when I was trying to decide how I wanted to approach resurrecting my files. Another option is to use the old dBase 1.x under dosemu under Linux. Actually, that may be the easiest way to do it, but maybe not the long-lasting correct way.

Girvin

#29

Walther Koehler-4 wrote

My doctors office uses a dBase based system for administration, keeping
patient records and so on. It has integrated LO for many purposes, i.e.
medical letters. As I was told, reading those dbf files using scripts is
easy
(dbf_dump), modifying dbf files from outside the program however tedious,
they use LO base for that purpose. Unfortunately, the SQL commands for
dBase
are limited.

I do a nightly second backup of the patient.dbf and have a Base document
connected to this backup file so this connection does not interfere with the
business application.