Extremely Slow Base Report Builder

Am 26.05.2012 00:47, Girvin R. Herr wrote:

As an update to my problem with Report Builder, my 1500+ record database
takes 94 pages of a Report Builder / Writer document. I put on my
patience hat and timed how long it takes to format the report, ready for
printing. As a baseline, it takes about 49 minutes to create the
original document. I cleared my preferences and re-entered them, using
mostly defaults and timed it again: 49 minutes. So it is not preference
corruption from previous versions. I then updated my java to 1.6u30 and
timed it again: 49 minutes. So, it doesn't look like Java is the
problem. I then went back to my original use of SQL from when I created
the report with the wizard, rather than using a query for the data and
timed it: 49 minutes! No matter what I do, it takes about the same
excruciatingly long time to build my report. What is really frustrating
is that there is no status popup to inform me of what it is doing. It
just goes out to lunch. Actually, it seems to initially create 128 pages
with header and footer, but no data, at the end of the first "sleep".
When the page status at the bottom of the writer window drops to 94
pages, I know it is done. Every so many pages, it does come back alive
for a second or two and then goes out to lunch again for several
minutes. Each time it returns, a few more pages are populated with data.
Girvin

Every time when there is a performance problem with this office suite, Tom blames Java. It has to be Java just because Java is evil.

Now this may be related to the one and only Java related performance problem and Tom does not even notice.

You are running the combination of Linux, Base plus JDBC?

Am 26.05.2012 00:47, Girvin R. Herr wrote:
>
> As an update to my problem with Report Builder, my 1500+ record database
> takes 94 pages of a Report Builder / Writer document. I put on my
> patience hat and timed how long it takes to format the report, ready for
> printing. As a baseline, it takes about 49 minutes to create the
> original document. I cleared my preferences and re-entered them, using
> mostly defaults and timed it again: 49 minutes. So it is not preference
> corruption from previous versions. I then updated my java to 1.6u30 and
> timed it again: 49 minutes. So, it doesn't look like Java is the
> problem. I then went back to my original use of SQL from when I created
> the report with the wizard, rather than using a query for the data and
> timed it: 49 minutes! No matter what I do, it takes about the same
> excruciatingly long time to build my report. What is really frustrating
> is that there is no status popup to inform me of what it is doing. It
> just goes out to lunch. Actually, it seems to initially create 128 pages
> with header and footer, but no data, at the end of the first "sleep".
> When the page status at the bottom of the writer window drops to 94
> pages, I know it is done. Every so many pages, it does come back alive
> for a second or two and then goes out to lunch again for several
> minutes. Each time it returns, a few more pages are populated with data.
> Girvin
>
>

Every time when there is a performance problem with this office suite,
Tom blames Java. It has to be Java just because Java is evil.

Now this may be related to the one and only Java related performance
problem and Tom does not even notice.

You are running the combination of Linux, Base plus JDBC?

Ah I missed that last bit - yup, those JDBC connections can suck - has
the OP tried ODBC?

//drew

Am 26.05.2012 13:32, drew jensen wrote:

You are running the combination of Linux, Base plus JDBC?

Ah I missed that last bit - yup, those JDBC connections can suck - has
the OP tried ODBC?

//drew

I was thinking of this problem which affects Linux+Java-DB+LibO before 3.5:

http://www.oooforum.org/forum/viewtopic.phtml?t=125253&highlight=java+linux

The problem has gone with LibreOffice 3.5 and it did not exist under operating systems other than Linux.

Hi :slight_smile:
I thought that the Calc route just read the data that is contained in the database?  I didn't think it converted it or export-imported it or dragged it in, i just thought it was another way of accessing the data.  Also i kinda had assumed that the Calc route would allow you to view Queries in the same way as you access normal tables.

I don't really understand everything in Andreas' links but it seemed to fit in with what Girvin was asking for.  Quite a few people here have been extremely helpful to people using Base but i only remember Andreas going on about the alternatives to the Report Builder.  Possibly Alex, Drew, Dan and others have mentioned things too but i just hadn't remembered anything i could find reliably.

It would be really good if a few of you experts in Base could write it up, maybe help Dan or expand on the work he has done.

In response to Andreas' "How would you write a guide for hammer, chisel, plow, saw and file?"
http://www.wikihow.com/Use-a-Hammer-Safely
"It is estimated that some 50,000 Americans seek treatment every year as a result of a hammer injury".  I guess it's similar in other countries but <rant> [deleted] </rant>]
http://artofmanliness.com/2009/09/29/how-to-use-a-hammer/
"A lot of men today are clueless when it comes to tools." <rant re:sexist> [deleted] </rant>
http://www.instructables.com/id/How-to-use-Vavles-Hammer-Editor/
http://www.hammernet.com/tips.htm
I'll ignore the bladed weaponry and activities that most people have no idea about (eg how many people really plow these days?! lol)
http://www.wikihow.com/Organize-Files
http://zenhabits.net/how-to-simplify-your-filing-system-or-why-stacking-just-doesnt-work/
http://www.realsimple.com/beauty-fashion/skincare/hands-feet/file-shape-nails-00000000002331/index.html
http://www.ehow.com/how_2034410_file-nails.html
http://www.nailsmag.com/article/474/getting-nails-into-shape
http://www.wikihow.com/File-Metal

Just because you know something so thoroughly well that it seems easier than falling off a bike doesn't mean that anyone else can cope with any of it.  Usually people that make something look easy have broken it down and worked hard at each step to make it smoother and less liable to break or go wrong or streamlined for speed.

Regards from
Tom :slight_smile:

drew jensen wrote:

  

drew jensen wrote:
8><...
    

Hi Tom

Really - you seem to know a lot, are you writing a manual?

@Girvin - there is no place that I've seen the report builder be that
slow and not have an installation problem - not saying it is impossible
but sounds really odd. 1500 records in a tabular report, 49 seconds is a
long time for that actually. There is one exception to that, graphics -
is your report including graphics stored in data fields?

On the other hand Calc, as has been pointed out, might be your preferred
path.

Best,

//drew

8><...

Hello Drew,
I understand what you are saying, but I installed the LO 3.5.2 binary (RPM) packages from the LO website. I repackaged them for Slackware, but that does not change the 1s and 0s, just unpacks the RPMs and re-packages the files into a Slackware package for installation. Therefore, if there is an installation problem, it seems to be in the LO packages. Note that I am using the Report Builder bundled into LO, not the version from the extensions website. I do believe the newest is 1.2.1 rev 2, and the one in LO is still 1.0-something. I have not tried to replace the bundled version with the 1.2 version.

I could live with 49 _"seconds"_. However, it is taking 49 _minutes_ for my report. My database is nothing special, just text and integer values. Nine elements plus the key per record. No graphics. So, yes, this problem does sound unusual. However, I have not been able to pin down the problem yet. In the meantime, I am looking into using Calc to print my data. It looks good and will do until I can get RB working.

BTW: The report is a simple text page header, Detail, and page footer, no graphics there either. I do have the date and time fields in the header, but that shouldn't bring it down. Actually, I do have some separator lines inserted at the bottom of the header and the bottom of each Detail line. Page number at the bottom of the footer. That's it.
Thanks for the help.
    

Hi Girvin

Sounds like it aught to run lickity-split...hmm

Anyway - looks like you are off to use Cacl.

You might want to do this.

When you open the data window under Calc, instead of copy/paste from the
data grid - grad, drag and drop the actual query name from the left side
of the data window. This will create a named range, you can set options
on the range to _not_ save the data in the spreadsheet, jut the
connection information...then when you open the spreadsheet again it
will re-run the query and update the data anew..

Best wishes,

//drew
  

Drew,
Yes! Your procedure worked fine! Thanks much. It will make using Calc to produce my reports a lot more error free. I have not tested the dynamic importation of the data yet, but even if it doesn't work, which I am sure it will, this procedure is much better than my copy-paste procedure. Another benefit of using Calc will be to save paper. Whereas the ORB output used 94+ pages, the Calc output, being more compressed, even with the separation grid, produces about half that number - 47 pages.

Your suggestion of an installation problem causing ORB to fail for me got me thinking and I realized I did modify one aspect of the LO distribution package. I moved the 2 executable files in "/usr/bin" to "/opt/bin". Just in case ORB was relying on these files being in "/usr/bin", the first thing I did today was to restore those 2 files in "/usr/bin" and try ORB again. No joy. It is now taking 66 minutes. However, since my last tests, I entered more data and now my database is 1800+ records. So that accounts for the increase in time. Note that it does not take anywhere near this amount of time to import the data into Calc. Calc does it in a few seconds, not tens of minutes.

Thanks very much for your help.
Girvin

Fernand,
I am assuming you are talking about the "Data" tab for the report where there are "Content Type" and "Content" option lists. I tried it both ways with the same results. Originally, I was using the SQL command(s) the wizard created when I first created the report. Those SQL commands accessed the data directly without using a query. I then changed it to use the Query I created, so I could calculate the total cost based on the quantity and unit cost data and pass it to the report for printing. Both versions of the report performed about the same.

I am using the same query for my Calc version of the report and it imports the data in a few seconds. So, I don't think that is the bottleneck.
Thanks for your help.
Girvin

Fernand Vanrie wrote:

Andreas Säger wrote:

8><...

-- When you drag the query icon from the left pane of the data source window onto a Calc cell you will get a semi-automatic link. Call menu:Data>Refresh to refresh the link.
-- When you drag selected row selectors you get a copy of selected rows. The top-left corner of a row set selects all rows. Same with queries, views and tables opened from some database window.
-- Dragging a query icon from the database window creates a refreshable link as well but the link breaks when the connection closes. Bug or not bug? Who cares?
-- From a form you can copy from the additional grid view. Hit the last button on the navigation tool bar.

The linked data range resizes dynamically with every refresh.
Any formula cells directly adjacent to the import range will expand and shrink with the resized data range. So the clearly defined row sets of a database enable dynamically resizing formula ranges. A feature that does not exist with a pure spreadsheet. Tons of silly macro code have been written for this.

Its properties are accessible via menu:Data>Define...
Below [More Options] we have 4 widely unknown options:
1) Contains column labels (always true for database imports)
2) Keep formatting: spreadsheet formatting overrides any Base formatting. Should be true by default.
3) Insert/remove cells: Do not overwrite/clear cells when the database range expands/shrinks. Should be true by default, particularly with resizing formula ranges.
4) Don't save imported data. Useful with very large row sets and when you want to refresh on open. Prompts for refresh when opening the file.

Andreas,
Wow! You gave me a lot to think about. I will have to experiment a bit with these suggestions.
Thank you very much for your help.
Girvin

Andreas Säger wrote:

Am 26.05.2012 00:47, Girvin R. Herr wrote:

As an update to my problem with Report Builder, my 1500+ record database
takes 94 pages of a Report Builder / Writer document. I put on my
patience hat and timed how long it takes to format the report, ready for
printing. As a baseline, it takes about 49 minutes to create the
original document. I cleared my preferences and re-entered them, using
mostly defaults and timed it again: 49 minutes. So it is not preference
corruption from previous versions. I then updated my java to 1.6u30 and
timed it again: 49 minutes. So, it doesn't look like Java is the
problem. I then went back to my original use of SQL from when I created
the report with the wizard, rather than using a query for the data and
timed it: 49 minutes! No matter what I do, it takes about the same
excruciatingly long time to build my report. What is really frustrating
is that there is no status popup to inform me of what it is doing. It
just goes out to lunch. Actually, it seems to initially create 128 pages
with header and footer, but no data, at the end of the first "sleep".
When the page status at the bottom of the writer window drops to 94
pages, I know it is done. Every so many pages, it does come back alive
for a second or two and then goes out to lunch again for several
minutes. Each time it returns, a few more pages are populated with data.
Girvin

Every time when there is a performance problem with this office suite, Tom blames Java. It has to be Java just because Java is evil.

Now this may be related to the one and only Java related performance problem and Tom does not even notice.

You are running the combination of Linux, Base plus JDBC?

Andreas,
Yes! Plus the "com.mysql.jdbc.Driver" class and the "MySQL (JDBC)" connection type option.
And I am using the "MySQL-connector-java-5.0.7-bin.jar" in the class path and the MySQL 5.0.67 server.
Sun (Oracle) Java version 1.6.0_30
All test okay, of course.
Thanks.
Girvin

Hi :slight_smile:
If you are re-compiling from Rpms then why not just compile from the original source code?  Is Patrick still involved with packaging things for the slackware repos?  If so then he might be worth contacting.  Apparently he used to be very helpful and approachable. 
Regards from
Tom :slight_smile:

drew jensen wrote:

8><...

Ah I missed that last bit - yup, those JDBC connections can suck - has
the OP tried ODBC?

//drew

Drew,
I am the OP.
No, I have not tried ODBC. The only configuration documentation I have been able to get for MySQL and Base, used JDBC. At the time, that documentation was not in the OOo/LO manuals. I had to search the web for it.
If you have links to LO/OOo configuration documentation for ODBC connection to MySQL, I would be willing to try it.
Thanks.
Girvin

Andreas Säger wrote:
8><...

I was thinking of this problem which affects Linux+Java-DB+LibO before 3.5:

http://www.oooforum.org/forum/viewtopic.phtml?t=125253&highlight=java+linux

The problem has gone with LibreOffice 3.5 and it did not exist under operating systems other than Linux.

Andreas,
Yes, this is the very problem I had a few months ago with OOo 3.3.0 when I updated my 1.6.0_11 JRE to 1.6.0.30 and brought Base to its knees. Someone on the OOo users forum told me about this one and suggested I back up to 1.6.0_22, the last Java known to work with 3.3.0. Note that the trouble i am having with ORB this time around is not quite the same. I am not having any speed problems with normal Base form data entry and searching. My problem seems to be limited to ORB. So, indeed, it seems to be fixed for Base, but maybe not for ORB.
Thanks for the help.
Girvin

Am 26.05.2012 22:13, Girvin R. Herr wrote:

Andreas,
Yes! Plus the "com.mysql.jdbc.Driver" class and the "MySQL (JDBC)"
connection type option.
And I am using the "MySQL-connector-java-5.0.7-bin.jar" in the class
path and the MySQL 5.0.67 server.
Sun (Oracle) Java version 1.6.0_30
All test okay, of course.
Thanks.
Girvin

Install Java 1.6.0_22 or LibreOffice 3.5.x and things will run with normal speed.

Tom,
No, I did not compile from source. I just repackaged the RPM binaries into the Slackware package format for installation.

I assume you are talking about Patrick Volkerding, the Slackware guru. I am not sure what his position is with the Slackware organization. He was very sick a few years ago and he may be cutting back. Slackware is still not bundling *Office in their Linux distros. It is a long story, but I am not using the latest and greatest Slackware, so I am pretty much on my own for the latest packages. That is why I package my own Slackware packages. Besides, it takes hours to compile OOo/LO. I would rather just re-package the binaries. I might note that I have done so for many years, since about OOo 2.4, without any known problems with the binaries - until AOO 3.4.0.

As far as compiling from Source goes, I tried that with OOo (AOO?) 3.4.0 and it was a disaster. Apache has dependency requirements that are, again, too new for my older versions. They even tossed GNU make for yet another make: "dmake", which looks like another PHD thesis result - not a major improvement on GNU make. For instance, they now require a newer glibc than I have. Since just about every piece of Linux software depends on glibc, the core library, I was not willing to bring my system down when something went wrong with the new glibc interface, just to be able to update AOO. That was the main reason I switched to LO. This latest version of LO (3.5.3.2) still runs with my older glibc. IMHO, that was a smart move on the Document Foundation's part. I could go on and on, but I digress.

Thanks for the help.
Girvin

Tom Davies wrote:

Andreas Säger wrote:

Am 26.05.2012 22:13, Girvin R. Herr wrote:

Andreas,
Yes! Plus the "com.mysql.jdbc.Driver" class and the "MySQL (JDBC)"
connection type option.
And I am using the "MySQL-connector-java-5.0.7-bin.jar" in the class
path and the MySQL 5.0.67 server.
Sun (Oracle) Java version 1.6.0_30
All test okay, of course.
Thanks.
Girvin

Install Java 1.6.0_22 or LibreOffice 3.5.x and things will run with normal speed.

Andreas,
I hate to tell you this, but I am already using LibreOffice 3.5.3.2. Or did you mean "and", not "or"?
Please don't make me go back to Oracle and try to open an account on their website just to download an archived Java version. I already tried that and when I goofed, thinking I entered 8 chars for the password and only entered 7, a bug in their system would not allow me to change my goof. Arrgh!
Thanks.
Girvin

Hi :slight_smile:
The java version you have should be ok.  We used to have a lot of trouble with the newer versions of java but with the 3.5.x branch that seemed to get sorted out.  So, it is better to try to stick with the newer versions of java.

Of course we will soon probably have to upgrade or patch due to some new and 'unforeseen' security flaw in java.  Some other programs almost never have security issues at all and only upgrade to add new features but with java it's just to fix whatever they broke or didn't fix last time. 
Regards from
Tom :slight_smile:

Tom,
Well, yes. But I remember the wise words of Adam Osborne, the entrepreneur who made the Osborne computer back in the 80s: "He, who lives on the cutting edge of technology, gets sliced to bits!"
I also am a firm believer in "if it ain't broke, don't fix it!"
Then there is "Never use a software program that has a version ending in zero!" That one has bitten me many times, such as OpenOffice 3.3.0 - very buggy. Now here we are with LO 3.5.3.2 (no zero) and it seems to work fine, other than the Oracle Report Builder extension, which is version 1.2.0 (zero again).

Usually, the only reason I update something is that something else requires the update and that something else has a compelling reason to need it. Or, as you say, it is a security bug fix.
Take care.
Girvin

Tom Davies wrote:

Hi Girvin,

If you have links to LO/OOo configuration documentation for ODBC
connection to MySQL, I would be willing to try it.
Thanks.

I wrote a tutorial for this very purpose many years ago for OOo, but it
would equally apply to LO today, things really haven't changed that much
(if at all) insofar as getting ODBC connections set up are concerned. I
can't actually find my English version at the moment, only the French
one I wrote, but note that John McCreesh also provided one that is still
available here :

http://www.unixodbc.org/doc/OOoMySQL9.pdf

Alex

Andreas Säger wrote:

Am 26.05.2012 22:13, Girvin R. Herr wrote:

Andreas,
Yes! Plus the "com.mysql.jdbc.Driver" class and the "MySQL (JDBC)"
connection type option.
And I am using the "MySQL-connector-java-5.0.7-bin.jar" in the class
path and the MySQL 5.0.67 server.
Sun (Oracle) Java version 1.6.0_30
All test okay, of course.
Thanks.
Girvin

Install Java 1.6.0_22 or LibreOffice 3.5.x and things will run with normal speed.

Andreas,
Here is some more data on the subject. I opened LO in a shell so I could catch any LO errors and then started my report build. The following enclosure was then displayed in the shell.
Note that the first 2 errors regarding library version information come up when I invoke LO, before I open ORB. My research informed me that these version errors are not fatal, despite the "required" tag. They are just a minor mismatch between my libraries and the ones compiled with LO. However, the "pentaho" errors, whatever pentaho is, may be significant, especially the Null Pointer errors.

----------------------------------------- Start of enclosure
501:$libreoffice3.5
/opt/libreoffice3.5/program/../ure-link/bin/javaldx: /usr/lib/libxml2.so.2: no version information available (required by /opt/libreoffice3.5/ure/bin/../lib/libjvmfwk.so.3)
/opt/libreoffice3.5/program/soffice.bin: /usr/lib/libpng12.so.0: no version information available (required by /opt/libreoffice3.5/program/libcairo.so.2)
May 27, 2012 12:36:40 PM org.pentaho.reporting.libraries.base.boot.AbstractBoot start
INFO: LibSerializer 1.1.6.10682 started.
May 27, 2012 12:36:40 PM org.pentaho.reporting.libraries.base.boot.AbstractBoot start
INFO: LibBase 1.1.6.10682 started.
May 27, 2012 12:36:41 PM org.pentaho.reporting.libraries.base.boot.AbstractBoot start
INFO: LibLoader 1.1.6.10682 started.
May 27, 2012 12:36:41 PM org.pentaho.reporting.libraries.base.boot.AbstractBoot start
INFO: LibRepository 1.1.6.10682 started.
May 27, 2012 12:36:41 PM org.pentaho.reporting.libraries.base.boot.AbstractBoot start
INFO: LibFonts 1.1.6.10682 started.
May 27, 2012 12:36:41 PM org.pentaho.reporting.libraries.base.boot.AbstractBoot start
INFO: LibLayout null started.
May 27, 2012 12:36:41 PM org.pentaho.reporting.libraries.base.boot.AbstractBoot start
INFO: LibFormula 1.1.7.10682 started.
May 27, 2012 12:36:41 PM org.pentaho.reporting.libraries.base.boot.AbstractBoot start
INFO: LibXML 1.1.7.10682 started.
May 27, 2012 12:36:41 PM org.pentaho.reporting.libraries.base.boot.PackageManager loadModule
WARNING: Exception while loading module: org.pentaho.reporting.libraries.base.boot.DefaultModuleInfo={ModuleClass=org.jfree.report.modules.gui.swing.common.SwingCommonModule}
java.lang.NullPointerException
        at org.pentaho.reporting.libraries.base.boot.PackageManager.containsModule(PackageManager.java:369)
        at org.pentaho.reporting.libraries.base.boot.PackageManager.loadModule(PackageManager.java:436)
        at org.pentaho.reporting.libraries.base.boot.PackageManager.addModule(PackageManager.java:330)
        at org.pentaho.reporting.libraries.base.boot.PackageManager.load(PackageManager.java:199)
        at org.jfree.report.JFreeReportBoot.performBoot(Unknown Source)
        at org.pentaho.reporting.libraries.base.boot.AbstractBoot.start(AbstractBoot.java:197)
        at com.sun.star.report.pentaho.PentahoReportEngine.<init>(PentahoReportEngine.java:45)
        at com.sun.star.report.pentaho.SOReportJobFactory$_SOReportJobFactory.createReportJob(SOReportJobFactory.java:328)
        at com.sun.star.report.pentaho.SOReportJobFactory$_SOReportJobFactory.execute(SOReportJobFactory.java:222)
May 27, 2012 12:36:41 PM org.pentaho.reporting.libraries.base.boot.PackageManager loadModule
WARNING: Exception while loading module: org.pentaho.reporting.libraries.base.boot.DefaultModuleInfo={ModuleClass=org.jfree.report.modules.gui.swing.html.SwingHtmlModule}
java.lang.NullPointerException
        at org.pentaho.reporting.libraries.base.boot.PackageManager.containsModule(PackageManager.java:369)
        at org.pentaho.reporting.libraries.base.boot.PackageManager.loadModule(PackageManager.java:436)
        at org.pentaho.reporting.libraries.base.boot.PackageManager.addModule(PackageManager.java:330)
        at org.pentaho.reporting.libraries.base.boot.PackageManager.load(PackageManager.java:199)
        at org.jfree.report.JFreeReportBoot.performBoot(Unknown Source)
        at org.pentaho.reporting.libraries.base.boot.AbstractBoot.start(AbstractBoot.java:197)
        at com.sun.star.report.pentaho.PentahoReportEngine.<init>(PentahoReportEngine.java:45)
        at com.sun.star.report.pentaho.SOReportJobFactory$_SOReportJobFactory.createReportJob(SOReportJobFactory.java:328)
        at com.sun.star.report.pentaho.SOReportJobFactory$_SOReportJobFactory.execute(SOReportJobFactory.java:222)
May 27, 2012 12:36:41 PM org.pentaho.reporting.libraries.base.boot.PackageManager loadModule
WARNING: Exception while loading module: org.pentaho.reporting.libraries.base.boot.DefaultModuleInfo={ModuleClass=org.jfree.report.modules.gui.swing.pdf.SwingPdfModule}
java.lang.NullPointerException
        at org.pentaho.reporting.libraries.base.boot.PackageManager.containsModule(PackageManager.java:369)
        at org.pentaho.reporting.libraries.base.boot.PackageManager.loadModule(PackageManager.java:436)
        at org.pentaho.reporting.libraries.base.boot.PackageManager.addModule(PackageManager.java:330)
        at org.pentaho.reporting.libraries.base.boot.PackageManager.load(PackageManager.java:199)
        at org.jfree.report.JFreeReportBoot.performBoot(Unknown Source)
        at org.pentaho.reporting.libraries.base.boot.AbstractBoot.start(AbstractBoot.java:197)
        at com.sun.star.report.pentaho.PentahoReportEngine.<init>(PentahoReportEngine.java:45)
        at com.sun.star.report.pentaho.SOReportJobFactory$_SOReportJobFactory.createReportJob(SOReportJobFactory.java:328)
        at com.sun.star.report.pentaho.SOReportJobFactory$_SOReportJobFactory.execute(SOReportJobFactory.java:222)
May 27, 2012 12:36:41 PM org.pentaho.reporting.libraries.base.boot.PackageManager loadModule
WARNING: Exception while loading module: org.pentaho.reporting.libraries.base.boot.DefaultModuleInfo={ModuleClass=org.jfree.report.modules.gui.swing.preview.SwingPreviewModule}
java.lang.NullPointerException
        at org.pentaho.reporting.libraries.base.boot.PackageManager.containsModule(PackageManager.java:369)
        at org.pentaho.reporting.libraries.base.boot.PackageManager.loadModule(PackageManager.java:436)
        at org.pentaho.reporting.libraries.base.boot.PackageManager.addModule(PackageManager.java:330)
        at org.pentaho.reporting.libraries.base.boot.PackageManager.load(PackageManager.java:199)
        at org.jfree.report.JFreeReportBoot.performBoot(Unknown Source)
        at org.pentaho.reporting.libraries.base.boot.AbstractBoot.start(AbstractBoot.java:197)
        at com.sun.star.report.pentaho.PentahoReportEngine.<init>(PentahoReportEngine.java:45)
        at com.sun.star.report.pentaho.SOReportJobFactory$_SOReportJobFactory.createReportJob(SOReportJobFactory.java:328)
        at com.sun.star.report.pentaho.SOReportJobFactory$_SOReportJobFactory.execute(SOReportJobFactory.java:222)
May 27, 2012 12:36:41 PM org.pentaho.reporting.libraries.base.boot.PackageManager loadModule
WARNING: Exception while loading module: org.pentaho.reporting.libraries.base.boot.DefaultModuleInfo={ModuleClass=org.jfree.report.modules.gui.swing.printing.SwingPrintingModule}
java.lang.NullPointerException
        at org.pentaho.reporting.libraries.base.boot.PackageManager.containsModule(PackageManager.java:369)
        at org.pentaho.reporting.libraries.base.boot.PackageManager.loadModule(PackageManager.java:436)
        at org.pentaho.reporting.libraries.base.boot.PackageManager.addModule(PackageManager.java:330)
        at org.pentaho.reporting.libraries.base.boot.PackageManager.load(PackageManager.java:199)
        at org.jfree.report.JFreeReportBoot.performBoot(Unknown Source)
        at org.pentaho.reporting.libraries.base.boot.AbstractBoot.start(AbstractBoot.java:197)
        at com.sun.star.report.pentaho.PentahoReportEngine.<init>(PentahoReportEngine.java:45)
        at com.sun.star.report.pentaho.SOReportJobFactory$_SOReportJobFactory.createReportJob(SOReportJobFactory.java:328)
        at com.sun.star.report.pentaho.SOReportJobFactory$_SOReportJobFactory.execute(SOReportJobFactory.java:222)
May 27, 2012 12:36:41 PM org.pentaho.reporting.libraries.base.boot.AbstractBoot start
INFO: Pentaho Reporting Flow-Engine null started.

---------------------------------------- End of enclosure
Null pointers are _*not*_ a good sign.
No further messages were output and I terminated the report generation process before it completed.
I would like to resolve this ORB problem, since the Calc solution has a couple problems with it. Mainly, I remembered last night that several of my reports have so much data in each record that they are printed with two or more lines of text in the report, which I don't believe can be done neatly in Calc.
Hope this helps resolve this problem.
Girvin