Bug 37620 - Data in reports created by Report Wizard do not display all data records in LO 3.4 RC1
Summary: Data in reports created by Report Wizard do not display all data records in L...
Status: CLOSED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
3.4.0 RC1
Hardware: x86-64 (AMD64) All
: high critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: regression
: 38229 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-05-26 03:34 UTC by Joseph Sylvester
Modified: 2011-12-23 13:26 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Sampe database exhibiting issue reported (193.84 KB, application/vnd.oasis.opendocument.database)
2011-05-26 03:34 UTC, Joseph Sylvester
Details
Error messages in console (3.31 KB, text/plain)
2011-10-27 02:07 UTC, Julien Nabet
Details
Screenshot of the 25 prescriptions (149.19 KB, image/png)
2011-10-27 04:21 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joseph Sylvester 2011-05-26 03:34:38 UTC
Created attachment 47186 [details]
Sampe database exhibiting issue reported

I am running Ubuntu 11.04. All my active databases were initially created in OOo 3. Under LO 3.4 RC1, all reports, originally generated with Report Wizard, do not print. The report displays the random letters in the variou fields as placeholders, but no real data prints. If the report was generated with Oracle Report Builder, the report prints fine. I have attached a representative database "Prescriptions". The report "Query Prescription", created in Report Wizard, does not print all data. The report "Presriptions by Physician", created with Oracle Report Builder, prints all data correctly.
Comment 1 Alex Thurgood 2011-05-26 07:12:16 UTC
Hi Joseph,

Confirmed on Mac OSX. The report named "Query Prescription" only contains a single line reference with Ipsum Lorem typesetter's latin. The link to the underlying data seems to have been lost.

I compared this behaviour with various versions of OOo, NeoOffice and LibO :

Neo 3.2.1 : works as intended
OOo 3.2.1 : works as intended
OOo 3.3.0 : works as intended
OOo-dev 3.4m0 : fails
LibO 3.3.2 : works as intended
LibO 3.4rc1 : fails

setting confirmed status and regression. Adding to list of blockers for release.



Alex
Comment 2 Alex Thurgood 2011-05-26 07:12:39 UTC
Setting OS to all.
Comment 3 Alex Thurgood 2011-05-26 07:16:50 UTC
upping priority and severity
Comment 4 Alex Thurgood 2011-05-26 07:20:19 UTC
This might not get fixed in time for final 3.4 release, as it currently works in 3.3.2, and 3.4.0 will probably have even quite severe known bugs that will possibly be fixed during minor version point releases (see modified release plan on wiki).

Alex
Comment 5 Petr Mladek 2011-05-27 03:26:30 UTC
I guess that less than 1% of LO users would be affected by this bug => it should not block the 3.4.0 release => lovering the severity a bit.

Of course, it is still considered an important bug and we will do our best to solve it for 3.4.1.
Comment 6 Alex Thurgood 2011-05-27 03:48:54 UTC
It might even be fixed by CWS fs35a, but that is too big to post here (2.2Mb zipped) and presupposes integrating CWS fs34b(dependent on source code from m104,m105 and m106).


Alex
Comment 7 Alex Thurgood 2011-05-27 04:00:47 UTC
This is unfortunate because one of the LibreOffice engineering mission statements is to reduce dependency on Java functionality, e.g. the ORB (among others), by replacing it with equivalent C++ components. We already have a C++ component in the shape of the built-in report designer (unloved and underdeveloped, but that was Sun's decision initially). This component now ceases to work correctly with 3.4. That sort of puts us in an awkward situation with regard to our engineering mission statement.

And just to give people an idea of how much the database module is used in general (I'm not implying anything in relation to this particular bug here), I can quote some recent statistics (17/05/2011) from only three language forums : 

http://user.services.openoffice.org/fr/forum/index.php
Writer :     5014 Sujets    30942 messages
Base :   2818 Sujets  16465 messages

http://user.services.openoffice.org/en/forum/index.php
Writer:     10047 Topics     51352 messages
Base:    4026 Topics    18487 messages

http://user.services.openoffice.org/es/forum/index.php
Writer:     1079 Temas   3855 Mensajes
Base:     706 Temas   3059 Mensajes

I imagine that the German language forum has similar statistics (but I haven't checked).


So Base usage is clearly not as unimportant as it is made out to be.

Alex
Comment 8 Joseph Sylvester 2011-05-30 05:18:51 UTC
I have just installed LO 3.4..0 RC2 (official) and this problem no longer appears. I do not know if this makes sense based on prior discussion of when proble, would be fixed.
Comment 9 Alex Thurgood 2011-05-30 06:47:10 UTC
Hi Joseph,

The problem is still present for me on a clean install of rc2 on Mac OSX. So apparently fixed for Linux, but not for Mac OSX (can anyone here test on Windows?)


Alex
Comment 10 Joseph Sylvester 2011-05-30 09:14:30 UTC
I did a fresh install of LO 3.4 RC2 on Windows running Vista and the problem still exists.
Joe
Comment 11 Joseph Sylvester 2011-06-03 08:26:47 UTC
The problem has reappeared under Linux (Ubuntu 11.04). I had opened the "Prescriptiuons" database file under Windows Vista using Openoffice 3.3 to print a report. Now, under Linux and LO 3.4 RC2, the problem has surfaced again.
Comment 12 Alex Thurgood 2011-06-13 02:29:34 UTC
*** Bug 38229 has been marked as a duplicate of this bug. ***
Comment 13 Drew Jensen 2011-09-23 17:33:04 UTC
Test system Libo 3.4.3, Ubuntu Studio 11.04 (64bit), Gnome, OpenJDK 1.6_0_22

Can NOT reproduce the problem with the test odb and reports - verified the number of records expected given the SQL command, including modifying the command to return 6 additional records forcing a second page - no problem.
Comment 14 Julien Nabet 2011-10-27 02:07:34 UTC
Created attachment 52816 [details]
Error messages in console

When I opened the report Prescriptions, I've got no prescriptions at all and have all the error messages I attached.
The result is like if I would have opened it in edit mode except that fields in title columns were no more grey.
Perhaps I did something wrong.
Comment 15 Alex Thurgood 2011-10-27 03:12:13 UTC
(In reply to comment #14)
> Created attachment 52816 [details]
> Error messages in console
> 
> When I opened the report Prescriptions, I've got no prescriptions at all and
> have all the error messages I attached.
> The result is like if I would have opened it in edit mode except that fields in
> title columns were no more grey.
> Perhaps I did something wrong.

Hi Julien,

Are you testing on master ?
The behaviour you see might have something to do with the Java wizards having been rewritten in Python on master, and perhaps this has affected the Report Wizard ??


Alex
Comment 16 Julien Nabet 2011-10-27 04:21:20 UTC
Created attachment 52821 [details]
Screenshot of the 25 prescriptions

Alex: you're absolutely right, I tested on Master and there have been changes on this part.
I reinstalled 3.4.3 after removing profile before (since I made some other specific tests).
I tried to reproduce the pb, I haven't succeeded in it and no error messages in console.
I attached the screenshot of the result which seems correct (since I find 25 like the corresponding query).

If you don't reproduce it with 3.4.3, I propose you to put this bug to RESOLVED/WORKSFORME (I'm not sure about "WORKSFORME" is the most appropriate).
Comment 17 Alex Thurgood 2011-10-27 05:25:16 UTC
This appears to work fine for me now on Mac OSX with LibO 3.4.3.

Closing report as resolved/worksforme as we can't assign it to any particular commit.




Alex
Comment 18 Björn Michaelsen 2011-12-22 05:53:33 UTC
RESOLVED, FIXED or CLOSED bugs cant be KEYWORD NEEDINFO.
Comment 19 Björn Michaelsen 2011-12-23 13:26:39 UTC
Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.