The report with (finally) 5 pages is being generated in Writer but ... if the report is going to have more pages (like >10), it is being generated (progress bar is working) but no content is displayed in Writer :( it stops with no error ... just blank report screen (either no data nor graphical objects) Still some problems with reports
wabik : can you provide a test case setup for us please ?
wabik: Are you using the included ORB (bundled extension) or a separately installed extension ? Which version of Java ?
Alex, I will try to prepare an example next week if I find some time .... ORB already provided inside LO and version of JRE I use is 1.7.0_55 ...
wabik: ok thanks
OK ... It is not about number of pages generated! What I tested is attached already to the bug. The test case is (Raport 1): 1. Table with 3500 (or so) entries. 2. Generated report which consisted of only table entries --> everything ok 493 pages Second test case (Raport 2): 1. The same table ... 2. Report prepared with some shapes --> Generated ... but at the end stops and halts with no result :( FAILED So it is number of pages or number of shapes generated inside the report which causes error?!
Created attachment 100969 [details] Database test with reports one good and one bad
Just to say it was LiO: 4.3.0.0.beta2 Build ID: a06aa316117a6ff0f05c697c82831c227812d810
Have tried it with the attached database. I have set Raport2 to limit 100 for a test. Works, but has the CPU (1 core) runs at 100% for a longer time. Then tried it with limit 200 and get a grey background without content, while the CPU is running at 100% - have stopped this process after some minutes. Then I tried to save the writer-file (limit 100). It needs nearly the same time as creating the file. It is the same behavior with LO 4.1.6.2. I don't know if we could say this is a Base-bug. I recognize also a problem to open the saved file. Note there are nearly 6000 shapes inside such a file and the whole report is created with frames in Writer. We could really say: The limit is reached for such a construction.
Robert: OpenOffice 4.1 can handle that with no problem but I can agree it takes a long time. I did that to see the immediate result (hanging) as you said: a grey background without content.
Report 1 opens on Mac OSX 10.9.3 and LO 4242, but I see no shapes, no lines in the table (these appear to be invisible), only letters/numbers (which I assume are the field data). The report has 367 pages according to LO. The Navigator shows no other objects in the document than 3 tables. For me this is a bug. If I save the report as a copy (Save as copy...) and re-open the ODT document, I see the table markings, but still no shape objects. Report 2 does not open on OSX 10.9.3 and LO 4242. It leaves the app in a strange condition, I can access the menus and other parts of the app, but the mouse cursor remains permanently on the hourglass icon, instead of the normal pointer. Setting as new, and platform all, since OSX is also affected.
Adding Lionel to CC, but methinks this is more of a Writer shape import/draw/rendering problem than a database one
Altered title to reflect findings
Alex: You cannot see shapes in Raport 1 because there are no shapes :) It is just to visualise the problem with the shapes :(
wabik : Attempting to open Raport 2 in LO 4132 causes LO to continuously consume memory until the application is deemed "not responding" on OSX and the spinning beachball status is attained.
Confirming on OSX. Changing OS to ALL.
Bumping ... Anything on that bug? For now Base reporting is useless at least for me :(
I confirm that the problem is the time that Writer takes to open the odt file; report builder takes a rather short time to generate it. Here are my tests comparing LibreOffice with Apache OpenOffice: - AOO 4.1.0 opening AOO-generated 100 entries odt: 1min20 - AOO 4.1.0 opening LO-generated 100 entries odt: 1min20 - LO 3.5.4.2 opening LO-generated 100 entries odt: 2min25 - LO 3.5.4.2 opening AOO-generated 100 entries odt: 2min25 - LO 4.2.5.2 opening LO-generated 100 entries odt: 1min35 - LO 4.2.5.2 opening AOO-generated 100 entries odt: 1min35
Created attachment 103082 [details] AOO-generated 100 entries odt
Created attachment 103083 [details] LO 3.5-generated 100 entries odt
No significant difference with LO 4.2-generaged 100 entries odt.
(In reply to comment #20) > No significant difference with LO 4.2-generaged 100 entries odt. Lionel, It is not only slow but it does not do anything ... it just stops with no result. Reports do not work with shapes :(
(In reply to comment #21) > (In reply to comment #20) > > No significant difference with LO 4.2-generaged 100 entries odt. > > Lionel, > It is not only slow but it does not do anything ... it just stops with no > result. > Reports do not work with shapes :( The tests of other people on smaller datasets suggest that it is "just slow", albeit I admit too slow to be usable in your particular usage scenario of a myriad shapes per entry). Since 100 entries take about 1:30 minutes on my machine, by extrapolation 3200 entries would take on the order of magnitude of one hour (assuming linear algorithms, which is not obvious... I'd bet we have at least some n*log(n) algorithms, and possibly some quadratic or worse...). I launched a test on the full dataset, for me LibreOffice 4.2.5.2 is "busy", but not locked up: I can open a "new" Raport 1, I can open a new document, I can open the table, etc. I haven't waited the full hour yet to see if something eventually comes out of it. Are you *sure* your LibreOffice is completely stopped, and not just slower than your patience?
(In reply to comment #22) > (In reply to comment #21) > > (In reply to comment #20) [CUT] > > Are you *sure* your LibreOffice is completely stopped, and not just slower > than your patience? Lionel, My patience is done ... after 6 hours of waiting Report 2 is not done and whole LO is blocked ... memory in windows process has reached 256 MB so maximum that can be set in LO Options/Memory and whole LO was blocked ... Nothing can be done except killing LO process. I am using Windows version of LO 4.3.0.3 on Windows 7 64-bit. Something more is broken ... As I suppose ... But maybe I am wrong ... Can you test Report 2? :)
(In reply to comment #23) >> Are you *sure* your LibreOffice is completely stopped, and not just slower >> than your patience? > after 6 hours of waiting Report 2 is not done and > whole LO is blocked ... memory in windows process has reached 256 MB so > maximum that can be set in LO Options/Memory and whole LO was blocked ... If you mean the "Graphics cache" setting, I don't think this is related per se. I have 50MB there, and my LibreOffice memory usage happily goes into gigabytes. > Can you test Report 2? :) I've tested report 2 (on a faster machine) limited to 100, 130, 150, 170 records; it gets ever slower as I add more records, but "in the end" LibreOffice wakes up. Getting to 174 records, indeed it seems to go in an infinite loop: 100%CPU utilisation for much longer than what is needed for 174 records...
Created attachment 103277 [details] backtrace of seeming infinite loop Here's the backtrace after it seems to spin infinitely. It does not exit SwTabFrm::MakeAll for a long time; I assume that's where the ~infinite loop is.
Created attachment 103278 [details] LO 4.2-generated 174 entries odt. LibreOffice seemingly in infinite loop
Lionel, Can we do sth with the bug? :) I can wait 1 min to get result but it should come finally :) Brgds, wabik
(In reply to comment #27) > Can we do sth with the bug? :) Sure, I'd be glad to review and commit a patch that fixes it :) Else, I hope a Writer developer will pick it up and fix it.
To Writer Developer, Can you do anything in near future? Thanks in advance! Brgds.
Just one question .... WHEN? Please fix it :)
Bumping the bug ... is sth going on with this bug? Thanks for the answer!
Nothing in here ... :( Too bad, but still waiting...
wabik: please, don't ping here without bringing new information (for example, you reproduce the problem or not with last LO version), it's quite useless.
Adding self to CC if not already on
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.