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

Le 14/09/11 19:14, Robert Ryley a écrit :

Hi Robert,

In order to market the package productively, some input from the base
developers would be helpful.  I personally want to know

1.  How integrated into writer, calc, etc. is base?

2.  What exactly do we want base to do?  Personally, if it isn't at
least somewhat compatible with MS access, I don't know what the point

I am not a developer, but I have been using the database stuff of
OOo/LibO since before it even became open source, i.e. back in the day
when it was still a proprietary StarDivision product - there has to my
knowledge never been a specific remit for the database functionality to
be Access compatible. It has always been more of a "offer the broadest
general support for as many db engines as possible" kind of approach,
and then this became a "provide a portable cross-platform single file db
solution", in order for Sun to try and offer something akin to MS
Access' own single file db solution.

This is why although it is possible to use LibO to read from MS Access
db files on Windows OS only, none of the reports, queries, forms etc
that are available in a MS Access file are exploitable. There is
currently no support for reading MS Access files on any other OS from
within LibO that I know of (possibly with an ODBC driver one can read
and write to Access files on Windows, but I wouldn't know). On Mac, it
is possible to have read-only MS Access ODBC driver connections by
paying for ActiveConnection's ODBC proprietary driver, but I haven't
tried it. On Linux, reading mdb files and their schemata is up to the
linux mdb drivers project, which are not integrated into LibO as far as
I know.

So the state of affairs with regard to actually using MS Access data for
anything other than reading on platforms other than Windows is pretty
grim. This has been a problem for more than 10 years.

3. To recruit developers, or at least make better use of current
volunteers, is there a willingness to explore/experiment with JVM
compatible languages that might speed up development time (after the
learning curve, of course)?  The info gained from using base revisions
might help other areas of the project without being too disruptive to
other sections of the code.  Also, working on something new and
"bleeding edge" would create some developer interest in communities
that wouldn't normally consider working on a "boring" office project.

I could be wrong, but anything that involves more Java will probably not
be immensely welcome in the project as the current trend is to try and
remove as much of the Java dependencies as possible.

5. There are a lot of smaller DB backends that could be used.  MySQL
and Postgress aren't the only ones.  SQLite is worthy of consideration
if it makes technical sense to scrap what is currently used.

Someone had started on trying to integrate SQLite into the code as a
replacement backend for hsqldb, but it appears that has stalled (or at
least I can't seem to find anything in the current code base relating to
that effort). It is currently built when compiling the mozilla nss
integration required for digital signatures, but apparently there are
known problems on some of the build systems (e.g. MacOS) because of
conflicts between system libsqlite and the one that is required for the
moz component.


Unsubscribe instructions: 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.