Data set timeout when generating report to PDF

Our application generates URL's to send to BIRT as such:

http://somesite/birt/run?__format=pdf&__report=somereport.rptdesign&rp_user=jsmith&rp_rpt_yr=2011

The reports are developed with a single "main" table that selects the main information from what we call a "header" data set and there are "sub" data sets within the main table row that retrieves address/contact information and builds a letter. In long running reports that generate PDF reports that contain 4000+ letters the main data set information prints out correctly, but the tables that display the "sub" data set information do not display after 75 letters. There are no data issues that would prevent these letters from displaying this information.

Is there an embedded time out for data sets that would cause a report generating to PDF to not display certain info? A report that displays about 4700 pages takes about 4 minutes to render. We are running BIRT 2.6.1.

Find more posts tagged with

Comments

mwilliams

I don't think there's a limit on this. I have not seen this issue before. Have you tried using frameset in your url, rather than run? Maybe separating the run and render tasks will cause a change. Let me know.

mzeevalk

It is very odd that the "header" data set (which retrieves 1 record per letter generated) renders all the way through the 4773 page PDF document, but once you get to page 75 the interior tables that take the header info to retrieve address information nothing is displayed. If I filter down so that the report renders 5-10 pages it renders fine. I am testing using framset in the URL instead of run and will post back with results.

mzeevalk

When changing the URL to:

http://somesite/birt/frameset?__format=pdf&__report=somereport.rptdesign&rp_user=jsmith&rp_rpt_yr=2011

the same results occur (actually it moved one record forward and 75 pages rendered correctly and starting on the 76th page through page 4770 the interior tables display no address information.

Any other recommendations?

Brasi

wow...

Brasi

my pc went crazy or lagged or something.. and apparently I misclicked on my "-" since it was suppose to go on the 15 posts someone else had and now are gone.

Brasi

THAT above is what I was trying to "-"

mwilliams

It looks like the spammer issue was taken care of. Are you able to reproduce this in a way that I can run it? I don't see a reason that this should be happening. I'd like to see it if possible.

mzeevalk

Unfortunately, I don't have the bandwidth to mockup a report similar for you too look at. I confirmed that it definitely has to do with the 4 tables pulling data from the "header" table data. As I take the tables within the "header" table out more pages render with the all the data populated. The queries aren't even that complex and I find it odd that the data from the "header" data set renders in the letter throughout the 4700+ pages. The one thing I am testing is to see if creating a group to see if that helps the performance. Very strange...

mzeevalk

Unfortunately, I don't have the bandwidth to mockup a report similar for you to look at. I confirmed that it definitely has to do with the 4 tables pulling data from the "header" table data. As I take the tables within the "header" table out more pages render with the all the data populated. The queries aren't even that complex and I find it odd that the data from the "header" data set renders in the letter throughout the 4700+ pages. The one thing I am testing is to see if creating a group to see if that helps the performance. Very strange...

mwilliams

Could you join the dataSets somehow to avoid embedding tables? I don't know.

Could you attach your design, so I can see the layout? Maybe I can mock something up real quick after seeing what your report is set up like. Let me know.

mzeevalk

I attempted to utilize a group and no difference in performance. Here is the report, I removed a lot of client specific items so it may look odd.

mzeevalk

Michael, do you have any suggestions on how reformatting the report may help this issue? Thanks for looking into this. I am going to combine some of the data sets to see if that fixes the data sets timing out.

mzeevalk

This issue was resolved once I combined all data sets aside from one into a single data set. This degrades performance slightly, but all data is now being displayed on the 4700+ page report. Should this be logged as a bug? I would think you should be able to have a table with embedded tables from other data sets. While the performance may be slower than having all data retrieved in a single data set, it still should not fail to display data after a certain number of records.

mwilliams

The only other thing I would suggest is downloading the newest version of BIRT and seeing if the issue still persists. If it does, this should probably be logged as a bug, because the report should not finish rendering before the inner data is gathered. Let me know what you see in 3.7.1!