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.
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
Setting OS to all.
upping priority and severity
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
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.
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
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
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.
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
I did a fresh install of LO 3.4 RC2 on Windows running Vista and the problem still exists. Joe
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.
*** Bug 38229 has been marked as a duplicate of this bug. ***
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.
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.
(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
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).
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
RESOLVED, FIXED or CLOSED bugs cant be KEYWORD NEEDINFO.
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.
(In reply to Alex Thurgood from comment #6) > 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). http://customwritingz.net/ > > > Alex Can you please send it to me? I need to see detailed information.