Problems importing an OO database into LO

I have an OO database, and am trying out LO, and am having at least one
problem. There is a form which is based on a query whose results are
displayed in a grid, and various fields are copied into subform fields to
allow me to update them. In OO everything is fine. The attached screenshots
show what I mean.
http://nabble.documentfoundation.org/file/n3890826/LOBaseBug.zip
LOBaseBug.zip

Hi :slight_smile:
It looks like the relationship between some of the tables has gone wonky.  Can you look at the relationships in the OOo and LO versions to see what is different?

The Base Guide hasn't really got into it yet but there is some stuff in Chapter 2 that you might find useful as it explains the theory quite well. 
https://wiki.documentfoundation.org/Documentation/Publications#LibreOffice_Base_Guide
Now just to find screen-shots and things!

The Faq misses out on relationships
https://wiki.documentfoundation.org/Faq
Regards from
Tom :slight_smile:

What LO version are you using?

What OS (operating system) are you using?

Does LO show the same table contents as OOo does?

Using Design View for the query is question: What differences do you see
for OOo vs LO?

--Dan

> I have an OO database, and am trying out LO, and am having at least one
> problem. There is a form which is based on a query whose results are
> displayed in a grid, and various fields are copied into subform fields to
> allow me to update them. In OO everything is fine. The attached screenshots
> show what I mean.
> http://nabble.documentfoundation.org/file/n3890826/LOBaseBug.zip
> LOBaseBug.zip

> --
> View this message in context: http://nabble.documentfoundation.org/Problems-importing-an-OO-database-into-LO-tp3890826p3890826.html
> Sent from the Users mailing list archive at Nabble.com.

     What LO version are you using?

What OS (operating system) are you using?

Does LO show the same table contents as OOo does?

Using Design View for the query is question: What differences do you see
for OOo vs LO?

Also what version of OO.o is the file coming from?

Good idea, but the relationships haven't changed from OO. The fields in the
grid which have relationships are "supplier" and "Region" (both links into
other tables by an identifier field). The former is displayed incorrectly in
the grid, the latter correctly.

"Name" and "comments" are both displayed incorrectly in the grid but are
simple text fields in the underlying table. These are both VARCHAR type, but
so is "style" which is displayed correctly.

The fields are displayed correctly in the subform fields: if you look at the
"Wine Name" and "supplier" boxes there's an entry there. There would be one
in the "comment"box, but that particular wine on show didn't have a comment.
So there's no consistency in terms of relationships and linked tables or
field types as to what's displayed correctly and what isn't.

I know the theory reasonably well (though OO/LO might have a different view
of relationships to, say, MS Access).

Thanks for the interest, Dan.

The answers are:

LO: LibreOffice 3.5.2.2
Build ID: 281b639-6baa1d3-ef66a77-d866f25-f36d45f

OO: 3.3.0 build 9567

OS: Windows 7 64-bit Home Premium

Table contents: They look the same. At least, there aren't any obvious
oddities. (I've not exported them and done a comparison!).

Query: The SQL looks the same (by eyeballing, again). And running the query
directly displays correctly. It's only in the form that it doesn't.

Form design: they look the same (eyeballing again). If there are any
differences in some of the drill-down properties I don't know. Is there any
way to get a textual version of the form definition to do a comparison on?

All the best,

More developments - I copied the database to a Linux system and it opens
correctly. So it seems to be a Windows-only issue.

But the formatting on the Linux system was terrible!

Hi :slight_smile:
Which disto?  Ubuntu?  Hmm, more to the point which Desktop Environment?  Unity, Gnome, KDE, LxDE or something unusual?  Usually you can change the appearance through

System/Utilities, Preferences or there might be a control-box
Often a right-click on the desktop can get you into some of the preferences.

Alternatively maybe it's just the fonts playing up?  Have you installed the mstcorefonts (or whatever the package is called now) to get the MS fonts that are probably being used.  Perhaps 'just' change the fonts of the forms and reports?  (But then you would have to install those same fonts on Windows if you wanted to use the front-end on Windows again)

Regards from
Tom :slight_smile:

Ubuntu. I think it's a fonts issue.

But the formatting isn't exactly the problem. I'm far more worried about the
problems in Windows, which is my normal desktop environment.

Not heard anything recently about my main problem (the fonts issue is a
sideline). Anyone got any ideas?

Try if a manual refresh helps. Use the button in the middle of the navigation
toolbar.
Work-around: Use the ID numbers together with a list box. So the actual
field value is the ID masked by the list box text. In addition you can have
an editable record set.

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

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

Hi :slight_smile:
There is no harm in using OpenOffice.  It's a good product and not really a competitor anymore.  It's more like we are 1 extended community with 2 legs and 2 products. 
Regards from
Tom :slight_smile:

I've not been keeping up with the OO/LO saga. It strikes me as a bit mad to
have two different products, each being developed with minimal resources,
trying to compete with the MS juggernaut. United we stand, divided we
fall..... But that's a bit off-topic.

Anyway, I've reported this as a bug to Bugzilla and will see what happens.

Hi :slight_smile:
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. MS Office tries
to be relevant to all markets by being heavily bloated and "able to do
everything" so it's far heavier, more bloated and slower than anyone would
really want if they had free choice.

Microsoft win by ensuring they remain dominant and by convincing people that
choice, diversity and fair competition are bad for consumers.
Regards from
Tom :slight_smile:

So how does development happen? There seem to be two bug lists, and as I've
demonstrated, they give different results on the same data (yuk).

MS win by persuading industry (who are by far the dominant buyers - we
single users are very much a minority and ignored by MS) that
intercommunicability is a major issue - which it is. I'm old enough to
remember when there were half a dozen different word processing programs,
and exchanging data with a colleague in a different company was a major
issue. So instead of the industry settling on a single document format, MS
jumped into the breach with a very indifferent WP progam called "Word". Far
inferior to Word Perfect, but it sold on the back of the OS (DOS in those
days). One has to admire Gates for his commercial and marketing acumen,
however much one dislikes his philosophy and the products.

Hi :slight_smile:
We are not all single users here! Far from it! There are a lot of
companies invested in LibreOffice/OpenOffice and even more if you include
other products that use the OpenDocument Format. Mostly they are not names
well recognised by "Windows desktop users" but some may ring a bell; Google,
IBM, Redhat, Canonical, Oracle, Novell
http://www.documentfoundation.org/supporters/

We used to keep a page on articles in the press including articles about
massive migrations to LO
https://wiki.documentfoundation.org/LibreOffice_In_The_Press
and OpenOffice.org used to keep a page showing some of the larger corporates
that used LO/OOo but it all became untenable as there are so many articles
and migrations out there
http://www.computerworld.dk/art/118467/koebenhavnske-hospitaler-dropper-microsoft-office
http://www.muktware.com/hacksheet/2306 "Copenhagen hospitals ... move to
using LibreOffice ... to save around 5.3 million euros"
http://www.pcworld.com/businesscenter/article/220739/libreoffice_software_is_here_to_stay.html
http://www.version2.dk/artikel/ministerium-faar-milliongevinst-med-skift-til-virtuelle-desktoppe-og-libreoffice-44101
In some non-English-speaking countries use of OOo/LO is widespread. For
some it's a political decision, ie would US companies all be happy paying
millions to a non-American company for a product that has American-English
only as a 2nd and barely supported language? In most of Europe LO/OOo has
around 20% of the market, in England it seems to be creeping up to around 1
or 2%.

Why buy a product from a rival and pay hundreds of thousands to them in
licensing fees when for a fraction of the price you can pay a few of your
own devs to join in with something that removes the need? That way
companies can target some developments to suit specific needs they might
have from time-to-time while benefiting from the development work done by
other devs working for different companies

Unfortunately while MS dominates the market, documents produced using MSO
2010 do not always display properly in MSO 2007 and only work at all in
earlier versions if you get the extra plugin. So, people are being pushed
into buying their latest product just before the newer MSO 2013 (or whatever
they are going to call it) gets released and then they will soon have to
re-purchase to keep up. There even appears to be a note from MS that users
need to upgrade to the latest MS OS as documents produced in the same
version of MSO will look different on Xp from Win7 and different again on
Vista.

I am not in the development team but i get the impression the LO devs work
through OOo bugs as well as the LO ones. LibreOffice has absorbed other
projects that had originally forked from OOo due to Sun not incorporating
all the required bug-fixes and developments from other companies or
individuals.

If MS are not careful then the interoperability argument is going to
increasingly favour non-MS products as we all use the OpenDocument Format as
a native format while also trying to support the various MS formats that are
all called the same name as each other but operate differently.
Regards from
Tom :slight_smile:

Glad to hear it. But IMHO Base is just nowhere compared to Access (which
itself isn't much to shout about). And OO Basic compared to VBA similarly.
As an ex-programmer I'm always keen to automate any process, but the OO
Basic learning curve turns many people off (as far as I can see from
bulletin board comments - even this one) before they even start.

Agreed that MS have problems in forwards compatibility. But that's an
impossible dream. Can OO version 1 open OO version 3 documents?

Unfortunately I'm too short of time to contribute to OO/LO development - I
suspect there's another 2-year learning curve.

Hi :slight_smile:
+1
re: Base.  It's potential is awesome and even as it is now it can do some pretty amazing things easily that Access makes difficult but even so Access seems to be easier for most normal uses.

I'm not sure about the Macro languages but LO/OOo seems to offer a choice of 4 languages, none of which have been successfully used for malware out in the wild even at the low percentage you would expect given market share but maybe that might change in the future, i'm not sure.

Hmm, my point about compatibility was badly made.  Forwards compatibility is always likely to be a problem but MSO seems to have problems with sideways (different version of Windows) and backwards compatibility, at least according to their installer's notes for MSO 2010.

Regards from
Tom :slight_smile:

ptoye wrote

Glad to hear it. But IMHO Base is just nowhere compared to Access (which
itself isn't much to shout about). And OO Basic compared to VBA similarly.
As an ex-programmer I'm always keen to automate any process, but the OO
Basic learning curve turns many people off (as far as I can see from
bulletin board comments - even this one) before they even start.

Agreed that MS have problems in forwards compatibility. But that's an
impossible dream. Can OO version 1 open OO version 3 documents?

Unfortunately I'm too short of time to contribute to OO/LO development - I
suspect there's another 2-year learning curve.

The whole office suite is about the ODF document standard. The database
connectivity is just a tiny extra. It lets you import arbitrary tabular data
into ODF documents for serial letters, labels and for calculation models.
Additionally you may attach very simple and very generic form controls (like
HTML forms) to ODF documents in order to write some data from your keyboard
or clipboard back into some editable database via ODBC or JDBC.
That's all. No more, no less.

The "database application" called "Base" exists only as a
http://en.wikipedia.org/wiki/Potemkin_village.
Nevertheless, this part of the office suite is extremely productive and
helpful as is.
In our small business we have almost no spreadsheet nor Writer document
which does not rely on some type of data source one way or the other.
Writer's mail merge feature is far from perfect but if you have at least one
fairly computer literate person able to write very simple SQL queries, all
you need is the information: "Write your serial letter into template X and
connect the document with data source Y and query Z". The editor does not
need to care if data source Y is a database, a spreadsheet, a csv file or
something else. With a few clicks the new letter is connected to the right
table.
In addition I implemented a small inventory database which is not offered as
a component of our proprietary business software. Everybody is happy with it
even though it is not as pretty and streamlined as it could be. With a few
lines of very simple macro code my database outperforms any "Excel
solution", let alone paper records. The first version was almost as good
with zero lines of macro code.

If you want to earn money with perfectly streamlined database solutions
based on the Base component you surely would have to overstretch the whole
thing. Even if you'd learn everything about that API it would not help much
because the thing behind the API is not ready for business and propably
never will be because that would take hundreds of thousands of code lines
far beyond the scope of the ODF document standard.