Problems importing an OO database into LO

users
#21

Well, I seem to have started off quite a discussion. It's interesting that
Andreas seems to agree with me that OO isn't really for programming. And the
use of ODF is extremely important for intercommunicability, a point which
isn't taken by many MS addicts.

But I'm not trying to use a database to write a form letter - I'm not even a
fully-fledged business, just a freelance pianist. But I do like to play with
applications, and occasionally write my own where I can't find a suitable
share- or free-ware one. And Base just doesn't work well enough - too many
bugs and I suspect not enough will to drive proper develop,emt - hence
Andrea's comments on "Potemkin".

Tom's comment on 4 languages being available is fine, but as the API's so
impenetrable I feel it would have been better idea concentrate on getting
one language right rather than four languages wrong! Others are at liberty
to disagree.

#22

What database doe you think works better than OpenOffice or LibreOffice?

#23

David-4 wrote

What database doe you think works better than OpenOffice or LibreOffice?

I don't.

I found MS Access as easy to use and with a better-developed macro language.
But I was not doing anything too complicated with it.

The over-complex API (or is it just the way the documentation works?) for
OO/LO and the lack of a decent IDE are real turn-offs for anyone trying to
do anything but the simplest task. For example, events aren't called when
the documentation implies that they should be (see
http://user.services.openoffice.org/en/forum/viewtopic.php?f=45&t=49924&start=30).
Bug? Feature? I don't know. But comments on that forum are as discouraging
are those here.

#24

Hi :slight_smile:

From what Andreas and others say i think that is most of the problem with Base.  Too many great ideas that only got half done.  I guess it might be the same with macros.

Apparently Andrew Pitonyak's guide is one of the best ways to get into macro programming
https://wiki.documentfoundation.org/Documentation/Publications#Programmers
Regards from
Tom :slight_smile:

#25

Tom wrote

Hi :slight_smile:

From what Andreas and others say i think that is most of the problem with

Base.  Too many great ideas that only got half done.  I guess it might be
the same with macros.

Apparently Andrew Pitonyak's guide is one of the best ways to get into
macro programming
https://wiki.documentfoundation.org/Documentation/Publications#Programmers
Regards from
Tom :slight_smile:

Yes, I've downloaded it and really will read it when I have a spare
month....

It seems very good, but omits Base entirely AFAICS.

#26

Hi :slight_smile:
True.  I was hoping it was 2 separate questions; 1 about Base and the other about macros.  Both together is likely to be tricky. 
Regards from
Tom :slight_smile:

#27

I prefer to use MariaDB/MySQL and use Base as a front end. There are other FOSS rdms available that might be more suitable to your needs.

#28

Hi :slight_smile:
Lol, i was expecting you to say Postgresql.  There are other much lighter-weight ones more suitable for small databases but we almost never hear about them.  Perhaps SqLite or something?  I guess this is a topic for a different thread. 
Regards from
Tom :slight_smile:

#29

ptoye wrote (13-04-12 16:30)

Manual refresh doesn't help. I'm afraid.

And the workaround is even simpler - keep using Open Office!

Looking at how little had been done there the last years with Base and how much in LibreOffice, I hardly can imagine you'll become happy there :wink:

Cheers,

#30

Tom wrote (15-04-12 13:34)

Well, in many ways it's really only 1 product but in other ways it allows
each to focus on slightly different niches in the market.

Well, LibreOffice came from the same code base. But seeing all that has been done for LibreOffice the last year, it's hard to say any longer that it's one product (in many ways). Much still is shared, yes that's true.

Cheers,

#31

I liked the old Lotus Approach database.
I moved from that to Apache/MySQL/PHP. If Base was as good as lotus was I would do my next project in Base, but I think I will stick with a [LW]AMP solution because I am confident of the results for at least the next 5 years.
steve

#32

What was it you liked about Approach (I used that too)?

I'm asking for feature ideas.

Regards
Mark Stanton
One small step for mankind...

#33

Hi Mark,

What was it you liked about Approach (I used that too)?

I'm asking for feature ideas.

As a former Lotus Approach user, off the cuff :

- multiple table query/update support

- add/delete/modify/clone data button objects that worked (similar to
Access and FileMaker Pro) ;

- errm, I seem to recall that it had a good relationships manager ;

- Lotus Smartscript (in other words a competent script recorder, script
programming API) ?

- BLOB/CLOB support - LO's is incomplete to say the least, and by
default only lets you play with images - getting a binary stream to
function (e.g. video, or music) into and out of a db is more or less
mission impossible - the current best (only?) practice is to use VARCHAR
for the file name, store the binary data independently and then use cURL
from Basic in an attempt to read the binary stream and turn it into
something useful - heaven forbid that you might wish to actually write
something new into the stream...

- reliable date type conversions !! (cf. the differences in Date types
within LO as a whole, I believe there are/were 3 different types (Calc,
Base and Basic !!) - oh and I forgot the Java date/time spec too !

- it just worked !! sorry, that was not a suggestion, but an opinion :wink:

Alex

#34

- multiple table query/update support

Multi-tabe query is available, surely? Where it's not available is in
file mode when there's no backing database engine. Or having I missed
somthing?

Multi-table update support is an SQL limitation, isn't it?

Mark Stanton
One small step for mankind...

#35

Am 16.04.2012 14:49, Mark Stanton wrote:

- multiple table query/update support

Multi-table update support is an SQL limitation, isn't it?

At least it requires that a foreign key is linked to another table's unique (primary) key, otherwise it is uncertain which one of the related rows you are going to update.

This has improved in OOo 3.3. with embedded HSQLDB:
SELECT "A".*, "B".* FROM "A" JOIN "B" ON "A"."ID"="B"."AID"
selects an editable row set from 2 related tables (A.PrimaryKey=B.ForeignKey).
For anything else there are subforms and list boxes. These two elements let you edit related tables in any case.

Comparing this supplementary tool set with a full featured database suite is not fair. Many people can not accept anything less sophisticated than MS Access. The difference amounts to a full decade with a multi-million dollar budget.

#36

Hi Mark,

- multiple table query/update support

Multi-tabe query is available, surely? Where it's not available is in
file mode when there's no backing database engine. Or having I missed
somthing?

Multi-table update support is an SQL limitation, isn't it?

Sorry, I should have been more precise :

Lotus Approach allowed a user to create a form based on a query of a
collection of DBF tables and then be able to update them via the form
(or an update statement) - of course, relationships/foreign keys needed
to be involved, but it did work. This was a particular plus point over
the single flatfile driver that we have always had with OOo and now LO.
In other words, it allowed for updates/writes to cross-table flatfiles
as far as I can recall. You can not do this with the flatfile driver of
LO - only a single DBF file can be updated/written to at one time, and
as for Calc or Excel, well they are just read only datasources within
the framework of Base.

I don't know how Lotus/IBM did this, but it was a very, very, neat feature.

Alex

#37

Sorry, I should have been more precise :

Lotus Approach allowed a user to create a form based on a query of a
collection of DBF tables and then be able to update them via the form

Yes, because Approach had a database engine. Base doesn't.

If you try to do this through Base with MySQL/MariaDB/PostGres/HQLDB..
anything that accesses an external (or, only in the case of the "internal"
HSQLDB database, an internal) database *engine* not files, it will work.

Regards
Mark Stanton
One small step for mankind...

#38

Mark Stanton wrote

Multi-table update support is an SQL limitation, isn't it?

Mark Stanton

I don't think so. As I understand it it all depends on the database engine
at the back of it all. Some allow it when it's not ambiguous, others don't.
HDBC doesn't.

#39

Am 15.04.2012 17:48, ptoye wrote:

Well, I seem to have started off quite a discussion. It's interesting that
Andreas seems to agree with me that OO isn't really for programming. And the
use of ODF is extremely important for intercommunicability, a point which
isn't taken by many MS addicts.

But I'm not trying to use a database to write a form letter - I'm not even a
fully-fledged business, just a freelance pianist. But I do like to play with
applications, and occasionally write my own where I can't find a suitable
share- or free-ware one. And Base just doesn't work well enough - too many
bugs and I suspect not enough will to drive proper develop,emt - hence
Andrea's comments on "Potemkin".

The Potemkin village mimics a full featured rural community but it is no more than a scenery. When you click through the items of a database window, it looks as if you could find everything you need. As soon as you kicked all tires you will notice that it does only a small portion of what it pretends to do.
Once you downloaded and studied some example databases, you will find a true village behind the pretty scenes. It provides everything you need to settle down: plain SQL, form design tools, various options to produce reports without builders nor wizards. The results not perfect but fairly well usable. Once you fully understand this extremely simplified tool set you may write some macros or extensions.

Tom's comment on 4 languages being available is fine, but as the API's so
impenetrable I feel it would have been better idea concentrate on getting
one language right rather than four languages wrong! Others are at liberty
to disagree.

As far as spreadsheets and text documents are concerned, I can find most of the objects within a minute.
The languages are all right. Python, Java, JavaScript are not developed by the LibreOffice team. The office API is completely independent from the language. There is an office API, a mature programming language and a few lines of glue code (bridge).
- You need to know a certain API basement right from the start (frame, controller, model, services, interfaces, structs).
- Of course you need to know the application on the GUI level very well.
- The language you are using should be familiar to you.
- You should know how to analyse the self-documenting UNO objects. There are powerful tools for this. I use to recommend the MRI extension. Even this development helper wants to be explored patiently.
As a developer you have to adjust yourself to the application before you can adjust the application to your needs. On API level this office is radically different from MS Office. This is because "economy" has a different meaning in open source context.
Starting with a concrete task imposing a deadline will certainly lead to frustration. That's what I learned with VBA 17 years ago. Once I really studied a well written VBA book, everything was quick and easy even though Office 95 had no code completion.
This API is just like any other complex API. This implies that it is by far more abstract (closer to the source code) than VBA which is a thick abstraction layer tailored around the respective office application within one particular OS. Porting VBA to the MAC succeeded after years of hard work because it was never intended to work on a system other than WIndows. This office suite does not have any such problems because it is not covered by thick sugar coating.

#40

...

What database doe you think works better than OpenOffice or LibreOffice?

Pick.