Bug 34410 - Base: Requests in LibreOffice 3.3 give incorrect values
Summary: Base: Requests in LibreOffice 3.3 give incorrect values
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
(earliest affected)
3.3.0 release
Hardware: All All
: medium normal
Assignee: Not Assigned
Depends on:
Reported: 2011-02-17 12:48 UTC by Robert Großkopf
Modified: 2012-01-25 12:00 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:

Query shows fields, which should be NULL, but were filled with values (4.56 KB, application/vnd.sun.xml.base)
2011-02-17 12:48 UTC, Robert Großkopf

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2011-02-17 12:48:08 UTC
Created attachment 43491 [details]
Query shows fields, which should be NULL, but were filled with values

When sending a request to the database which should show empty fields
this fields are filled with "0" (instead of NULL) if they are 'integer'
or the fields are filled with "03.01.1" (instead of NULL) if they are
'date' and must be filled in the table. In OOo 3.1.1 these fileds are empty in the GUI.
Comment 1 Alex Thurgood 2011-02-18 00:22:29 UTC
I can confirm this behaviour.

Tried the attached ODB in the following versions on Mac OSX 10.6.6 :

NeoOffice 3.1.2 patch4 : null values correctly displayed as blank
OpenOffice 3.2.1 : null values incorrectly displayed
OpenOffice 3.3.0 : null values incorrectly displayed
LibreOffice 3.3.1 RC1 : null values incorrectly displayed

In particular, the null date values are considered to be beyond the oldest date that LibO / OOo can display, and so are shown as the year 1901.

The problem actually appears to have been introduced with OOo 3.2.x and was not picked up on. 

Comment 2 Alex Thurgood 2011-05-15 08:25:57 UTC
Setting platform/arch to all.

Comment 3 Björn Michaelsen 2011-12-23 11:45:28 UTC
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 4 Robert Großkopf 2011-12-24 00:31:04 UTC
Behavior is still the same in LO 3.5.0 beta 2 linux-rpm-x64.
Comment 5 Julien Nabet 2012-01-21 02:29:03 UTC
I don't reproduce the bug with sources from branch 3.5 updated today.
(PC Debian x86-64)
It seemed it have been resolved in the same time as fdo#44813.
More precisely, I would say the commit ee1510922d7d0c5b8e111437d933078a62eda4b4 fixed this.

robert:Could you please try again with rc1 ?
Comment 6 Robert Großkopf 2012-01-21 03:17:29 UTC
I have tested it with LO 3.5.0 RC1, Linux rpm 32bit (Build-ID: b6c8ba5-8c0b455-0b5e650-d7f0dd3-b100c87). The behaviour (with the attachment in this bug) is still the same. 0-values in Abfrage1, where it must be NULL, date in the german format 03.01.1 where it should be NULL.

Comment 7 Julien Nabet 2012-01-21 08:41:10 UTC
robert: It seems the commit has been made before the rc1 but since it has been pushed just after the tag rc1, it couldn't be in the rc1 release.
So it should be there on 3.5.0 rc2 which will be released next week (http://wiki.documentfoundation.org/ReleasePlan/3.5#3.5.0_release)
Sorry for the confusion between the commit date and push date.

Don't hesitate to test 3.5.0 rc2. and keep us informed.
Comment 8 Robert Großkopf 2012-01-25 12:00:38 UTC
Problem is solved with RC2 of LO 3.5.
Many thanks!