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


Le 02/08/2016 à 00:23, Ian Whitfield a écrit :

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




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

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.