Efficiency question -- Will hidden table consume resources?

Greetings,

The reports I'm creating typically support two basic output formats: summary and detail.

In some of my existing reports I have a single table with detail rows, group headers, group footers, and table headers and foots set to visible or invisible depending on the output format.

Since the same table is used for summary and detail output, they can be a little more difficult to maintain down the road.

My solution to this is to just create two tables in the report, one for summary and the other for detail. Then I can just hide one whole table or the other.

However I'm concerned that BIRT will waste memory and cpu cycles on the hidden table. Is this the case? Or can I use scripting to drop a table on the fly?

Thanks!

Find more posts tagged with

Comments

mwilliams

Hi roopurt81, 
 
This devShare post shows how to drop a table based on a parameter. This parameter is user selected, but you could also pass a hidden parameter to decide which to drop. 
 
<a class='bbc_url' href='http://www.birt-exchange.org/devshare/designing-birt-reports/1027-drop-a-table-based-on-a-report-parameter/#description'>Drop a Table Based on a Report Parameter - Designs & Code - BIRT Exchange</a> 
 
Hope this helps. Let me know if you have questions.

roopurt81

Thanks again for your assistance Michael. I'll be checking that out in the next day or two.

(edit) Ok I got to it faster than I thought. Worked great! Thanks!

mwilliams

You're welcome. Glad to help!

weijenli

Hello,

I have a similar issue about tables. If I need to display two tables with identical content in a report. Do I have to access the DB twice? Or is there a faster approach?

Thank you.

Weijen

mwilliams

Hi Weijen,

What version of BIRT are you using? I was under the impression that newer versions of BIRT had better data caching and only accessed the DB once if two items were using the same content. Have you checked to see if you're getting two hits on the DB?

If using the exact same data with no extra filtering needed, you can use the first table as the source for the second table.

roopurt81

I had an experience that may assist in answering this. I'm a PHP developer so my front-ends are written in PHP-generated XHTML. When a user requests a report, my PHP applications make a HTTP request to BIRT deployed in Tomcat behind the scenes. One of the report parameters is a URI to a PHP page that generates the XML for BIRT.

Essentially what I'm saying is:
1) User requests report
2) PHP sends request for report to BIRT in Tomcat
3) BIRT sends request back to PHP for XML data
4) PHP returns XML data back to BIRT
5) BIRT runs report and returns it to PHP
6) PHP sends the output to the user.

So while developing reports with BIRT 2.5.1 some of them were really slow and others were causing various timeouts throughout the components of my application (PHP, Apache, Tomcat).

Via logging I was able to determine that BIRT, on average, was making the request to PHP for the XML data 3 times per report run. On average, my reports in this application contain one XML data source, 2 data sets, and two tables.

Anyways I modified my application logic so that PHP catches the initial user request, generates an XML file in memory mapped disk space, and then makes the request to BIRT and just gives it the filepath to the XML file.

It probably still hits the XML file several times in generating a report, but at least now it's just a simple file read and not running all sorts of application logic and database queries and re-generating the file every time.

weijenli

Hello guys,

Thank you for your reply. Actually, I found I was binding my tables to the data set instead of the previous BIRT element.

Another issue is that when I have a table within another table. The "where" query of the inner table depends on the outer table's result, hence it accesses the inner table when rendering each row. When the data grow, BIRT becomes slow.

What I do is to put all select results in a huge ugly temporary table and use group by and filter in BIRT.
This works for simple cases, but not good for some complex reports in which there are complex structures.

Weijen