Complex Reporting: Part 5 - Wrap up
Over the last four parts (1, 2, 3, and 4), you’ve seen how to build this complex SRS report. However, there are a few key points to consider when building reports like this:
Scalability issues – This is not a scalable solution, neither in terms of computation cost nor development cost. Sub-reports add significant overhead to CPU and RAM, and for each year you want to include, you must add more SQL. Thankfully, in this example, we only had 3 years and 3 commodities. In the real-world case that inspired this, it was also limited to three years with fewer than 25 items, so performance considerations were manageable.
Export limitations – The Export To option in SRS supports various formats (PDF, Excel, etc.), but Excel export has a critical flaw: sub-reports inside table cells aren’t supported—you’ll just see a gray block where the sub-report should be. PDF, TIFF, and web archives, however, work fine. If your users expect to export to Excel, you may need to reconsider using this approach.
Alignment issues – To prevent misalignment, ensure that the width and height are consistent across all reports and sub-reports, and that cells are locked to prevent expansion or shrinking. Without uniform dimensions, your cells may not align properly between reports and sub-reports, resulting in a disjointed appearance.