Robert MacLean
14 August 2008
Over the last four parts (1, 2, 3 and 4) you’ve seen how to build this complex SRS report, but there are a few points to be aware when building reports like this, first this is not a really scalable solution, both in computation cost and development cost. Sub-Reports add a lot of over head to the CPU and RAM and the fact that for each year you want to include you have to add more SQL. Thankfully in this example we had 3 years and 3 commodities. In the real world, which inspired me, it was also only three years with a low number of items (sub 25) so the performance considerations were ok.
The next problem is the Export To option in SRS, where you can export to a variety of formats such as PDF, Excel etc… Having sub-reports within table cells is NOT supported by the Excel one, you just a gray block were the sub report would be. PDF, TIFF, and web archive all work fine. If your users are expect to export to Excel you need to rethink using this.
Lastly you have to make sure you set the width and height and lock the cells on the report and sub-reports to not expand and shrink. If you don’t get the width/height the same all over what happens is your cells don’t align between the report and sub-reports and it looks shocking.
The next problem is the Export To option in SRS, where you can export to a variety of formats such as PDF, Excel etc… Having sub-reports within table cells is NOT supported by the Excel one, you just a gray block were the sub report would be. PDF, TIFF, and web archive all work fine. If your users are expect to export to Excel you need to rethink using this.
Lastly you have to make sure you set the width and height and lock the cells on the report and sub-reports to not expand and shrink. If you don’t get the width/height the same all over what happens is your cells don’t align between the report and sub-reports and it looks shocking.