![[TEST] Document Foundation Community](https://communitytest.documentfoundation.org/images/discourse-logo-sketch.png){kind=logo}
All:
Currently, LibreOffice Viewer only ods, odc, and odp files.
Are there any plans for it to support odg and odb files, in the
near/mid/long term future?
In theory, in as much as the draw engine is a subset of the presentation
engine, odg support should be currently available.
jonathon
There are generally no "grand plans" in LibreOffice absent a few limited circumstances. People can do as they like. If someone with the skills decides to tackle this finds it interesting enough to do, they'll do it, else, it won't get done. That about sums it up.
My guess is this will never be done. You should report an enhancement request on the bug tracker if you want it to at least be documented.
Best,
Joel
I can't see any support for ODB files coming anytime soon. A viewer for
ODB files would need at least to have a Java VM, or be able to
instantiate one, and at least hsqldb.jar and/or embedded firebird db
engines and probably a few other jar files (e.g. for reports), or be
able to access them on whatever system it was installed, and that is
just for the currently embedded databases. If someone wanted a viewer
for ODB files that use a separate db engine, that would require a whole
other specific development.
Alex
instantiate one, and at least hsqldb.jar and/or embedded firebird db engines and probably a few other jar files ...
...
for ODB files that use a separate db engine, that would require a whole other specific development.
Thanks. I hadn't thought about having to port the database engines.
(For some reason, I keep thinking that LibO uses SQLite.)
jonathon
Hi 
SQLite can be used as a back-end for Base, as can many other database
programs. One of the strengths of LibreOffice/OpenOffice Base is that it
is designed to use a wide variety of back-ends.
Regards from
Tom )
It can, but:
- it isn't used by default, nor is it likely to become more prevalent in
the foreseeable future because ;
- the LO code that handles database driver support and the built-in SQL
parser would require an extensive rewrite/extension in order to support
SQLite - the main problem with SQLite in relation to its use in LO is
its lack of strong data typing - many data types are stored as strings
in SQLite, which doesn't bode well when trying to determine whether the
string is a date, a timestamp, a large number, or some other kind of
information that might be able to be represented in one of the various
flavours of the SQL standard - in other words the type would have to be
"magically" inferred or intepreted by LO, and this functionality is not
currently available (nor is it planned).
Alex
the main problem with SQLite in relation to its use in LO is its lack of strong data typing
Data typing and SQLite are mutually exclusive concepts.
in SQLite, which doesn't bode well when trying to determine whether the
string is a date, a timestamp, a large number, or some other kind of
As far as SQLite is concerned, there is no difference between an
integer, and an mp4 video file.
For those who don't pay attention to what they are doing, such things
can have unexpected, and occasionally undesirable results.
There is that fringe minority, that sees such data ambiguity as a virtue.
jonathon
Hi
Ok, so is it just SQLite that is an odd exception or was the general 'rule'
i gave completely wrong?
I'm under the impression that Base works well with Postgresql,
MySQL/MariaDb, Hsqldb (as an external back-end), Firebird and many/most(??)
others? Also that the kinda default way iof using Base is to use some
external back-end - despite an internal one being hastily thrown on years
ago in order to downgrade Base to be more like Access?
Regards from
Tom
Hi
Errr, sorry my question looks so rude! I am honestly just curious and
wondering if i have been wrong, and giving wrong advice as a result! If i
am wrong it wouldn't be hugely unusual but i'd like to be able to give
better advice in the future.
One of my main reasons for joining this mailing list in the first place was
to learn from others and i feel i have learned quite a lot from the people
here over the years but i am aware that i misunderstand quite a lot of
things that people say.
Regards from
Tom
Greetings Tom,
I can attest that Base works well with MySQL/Mariadb (M/M). I understand that Base still requires the Java Connector (mysql-connector-java) to talk M/M to the server (aka "Back End"). At least that is how I still have Base configured. There was talk of a "native" Base driver for MySQL, but to my knowledge, that has not been deployed to date.
Girvin
Errr, sorry my question looks so rude!
Not rude. More like an exclamation of surprise, such as when the referee
knocks out the football player.
wondering if i have been wrong, and giving wrong advice as a result!
Base works well with most database engines. (I always had issues with
the Jet Database Engine.)
I was specifically referring to SQLite, which, as far as database
engines goes, manages to break every rule out there, whilst remaining
ACID compliant.)
despite an internal one being hastily thrown on years
I wouldn't say "hastily thrown on".
There was a fair amount of discussion about which database engine to
use. the major choices were SQLite, and HSqldb. One of the major
objections to using SQLite was the absence of data typing. (I think
that one can say that technically, SQLite does do data typing, and that
it pays more attention to data types today, than it did back in 2000.
However, for all practical purposes, there is no data-typing.)
ago in order to downgrade Base to be more like Access?
I wouldn't call it a downgrade
The Jet Database Engine, especially back in 2000, was crap. Data
corruption was a given. If you didn't back up the database before you
used it, your data would be trashed, when using it. If you did backup
your data, then it wouldn't be trashed.
Originally, Base was a front-end UI to connect with any database engine
out there. However, Base didn't provide the front end experience of
dBase 3, or Access. The dBase 3 clone that was built into OOo, had its
own separate front end, independent of Base. As best as I can tell, that
functionality is still present. OTOH, I haven't tried using it since
circa 2007. (^1)
Users migrating from MSO expected a database engine, to be included in
their office suite. Nobody told them about the dBase 3 clone in OOo.
(Small mercy, because that UI was a disaster area.) Consequently, a
database engine was incorporated into OOo. Then users complained,
because it didn't enable one to create forms, and other things, the way
that MSO does. Somebody wrote a set of macros, that gave LibO, the same
type of form interface as MSO. Somebody else came up with a way to
include those forms, and other things, in the resulting database.
The net result is that one can create databases with LibO, including
forms, as easily as on MSO. (Actually, I'd say that the resulting forms
are better, because they can export directly to Write, and get
pretty-printed there. I don't remember if one can go straight from form
to PDF, or if one has to go through Write, first.)
Hi
Thanks :))
That confirmed what i believed and added some detail i hadn't been aware of
at all. I hadn't been at all aware of the dBase 3 part and although that's
as clear as mud to me right now it's not something i feel i need to
understand any better. It kinda sounds like there is some sort of
duplication of functionality that would be a nightmare to unentangle.
My experience of MS's jet-engine was that it kinda worked just fine but i
take the point about Murphy's Law wrt back-ups for it - ie the only way to
ensure you don't need a back-up is to go to the trouble of making one.
Although i did once make a back-up of one at work and needed it right
away.
Anyway, thanks Garvin and Jonathon for fixing my existential anxiety so
quickly ! :))
Thanks and regards from
Tom
Just to put history into context:
When Sun released StarOffice 5.2 after buying it from StarDivision, it
had both the db3+ engine implementation, which has remained rather
limited to date compared to other db3/4 engine implementations that were
around at the same time (e.g. Lotus Approach, Paradox, etc), and the
Adabas D 11 Personal Edition engine, which was limited to a maximum size
of 100Mb on disk and at most 3 users in a client/server setup.
If you want to have a look at what it offered, in brief, you can check
out the following link :
http://valaurea.free.fr/documents/so52_adabas.html
Sun dropped integration of Adabas when it released OpenOffice.org, and
subsequently integrated the hsqldb engine with the V2 release of
OpenOffice.org. The rest is history, as they say.
Alex