[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#617596: libreoffice-base mangles data on trivial .odb database



Hi,

On Wed, Mar 09, 2011 at 03:42:18PM -0500, Daniel Kahn Gillmor wrote:
> Package: libreoffice-base
> Version: 1:3.3.1-1
> Severity: grave
> Justification: causes non-serious data loss

Come on. You see this in the *first* entry you do in the table. Immediately.
And you get a report with *THAT* record, you have to fix it then anyways.

I'd more argue that this is important.

> The data loss here is "non-serious" only because this is a trival
> database.  If i had this happen to a database that i cared about, i
> would be unhappy.

If I had a database I would care about I'd not use Base. And Especially not
hsqldb.

Actually I am seriously surprised that you do :)

>  0) run "libreoffice"
> 
>  1) click "Database"
> 
>  2) choose "Create a new database", click "Next"
> 
>  3) "Yes, register the database for me" (it's not clear what this
>  means), and "Open the database for editing"; click "Finish"
> 
>  4) choose a file name ("test.odb") and click "Save"

So it's hsqldb... If you had a database you cared about you probably
would use MySQL or PostgreSQL via the connectors ;-)

>  8) on "No primary key: Should a primary key be created now" prompt,
>     choose "Yes" (i observe that it creates a column named "ID" in
>     addition to the "id" column that already exists.  maybe this is
>     the root of the problem?)

Well, there I question your actions. You have an "id" and then still leave
LibO to do your primary key? Why not cancel and fix to make id primary key?
It shouldn't break this way, admittedly, but I would have expected pepople
to fix it if they *added an 'id' themselves*.

Anyway, confirmed. OpenOffice.org 3.2.1 seems to give a "NumberFormatException"
in the same scenario.

This seems to be related to the folllowing I found at
http://rlogiacco.blogspot.com/2009/03/hsqldb-no-such-table-exception.html:
"
Well the problem is HSQLDB converts all identifiers to upper case unless you use the double quote notation!!!! The query then should be issued as

    select * from auth."property"

If you query the database meta data you can see the problem in the auth schema name: it's real name is AUTH, all uppercase letters!

The problem here is HSQLDB is case sensitive but implicitly converts all your table names and column names to upper case! Yes the problem occur on column names too, in fact the following query fails with a No such column exception:

    select "id" from auth."property"

Thats because the id column was implicitly renamed to ID... sigh!
"

Grüße/Regards,

René
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  rene@debian.org | GnuPG-Key ID: D03E3E70
   `-   Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70



Reply to: