There are a large number of articles about how Pie Charts are Evil. Now evil is overstating it and there are times pie charts are appropriate. But the vast majority of the time when pie charts are used – they shouldn't be. (I think this is mostly due to people assuming pie charts are the standard way to display percentages.)
The same holds true for banded reports. There are cases where their use is appropriate, but that is a very limited sub-set of where they are used.
So what are banded reports? This is the approach used by Crystal Reports, SSRS, Pentaho, Jasper Reports, Actuate, etc. A report by definition is composed of a report header, a table, and a footer. The table component can have multiple levels of detail, with aggregation at those levels (this is where the term banded comes in).
When this fits the report you want, a banded report is a great solution. If the data comes from a single stored procedure, all you want to display is the data in the single table, and the detail levels and aggregation desired are easily set in the report designer – a banded report designer works well.
But when your needs are different, or more, then this locked in approach becomes a significant problem. Fundamentally banded reports are about limitations. Limitations that can be broached only with great effort and significant compromises.
So when should you look at an alternative approach?
The beauty of free-form (as opposed to banded) report design is you can do anything you want. You select the data you need within the report, you iterate over any data, in any way, across any part of the template. You insert sub-reports as desired and they become part of the template populated with the data you are iterating over. You include charts, gauges, bitmaps, hyperlinks, etc. wherever under any criteria you wish.
With free-form a detail sub-set can be any set of data you wish (even from another database) broken out over any part of the template you wish (not just rows). There is no such thing as a report header, table, and footer, there is just the template where you can place anything anywhere. With free-form, you can structure your report any way you can imagine.
For the cases where the strict structure of a banded report designer is difficult and/or limiting, please take a look at Windward Reports. With Windward you design your reports in Microsoft Word, Excel, or PowerPoint. It provides you a totally freeform report designer, both for layout and formatting. Wicked fast, extremely easy, and very powerful.
So next time you want to tear your hair out over the limitations or difficulity in your banded report designer, take a look at a freeform alternative. It will turn something difficult/impossible into something very easy.
The same holds true for banded reports. There are cases where their use is appropriate, but that is a very limited sub-set of where they are used.
So what are banded reports? This is the approach used by Crystal Reports, SSRS, Pentaho, Jasper Reports, Actuate, etc. A report by definition is composed of a report header, a table, and a footer. The table component can have multiple levels of detail, with aggregation at those levels (this is where the term banded comes in). When this fits the report you want, a banded report is a great solution. If the data comes from a single stored procedure, all you want to display is the data in the single table, and the detail levels and aggregation desired are easily set in the report designer – a banded report designer works well.
But when your needs are different, or more, then this locked in approach becomes a significant problem. Fundamentally banded reports are about limitations. Limitations that can be broached only with great effort and significant compromises.
So when should you look at an alternative approach?
- You want to display data outside the single table. Something as simple as placing the total of an invoice in the header rather than at the bottom of the table can be difficult to impossible.
- Multiple datasources used in a single report are difficult to impossible, because the table is tied to a specific dataset. For example, if you want a report showing a table of each salesperson's sales that month, followed by charts showing their telephone & email stats, then the same for the next sales rep. This is distinct data from two different databases laid out independent from each other.
- The banded table does not provide sub-detail and/or aggregation on the criteria you need. If the designer does not provide the functionality within the table – that's it. No way to get it. The limitations you hit in this approach tend to be absolute.
- Report details are broken by row (or column). You cannot iterate over the rows of data returned in any other way. For example if you can have multiple contact names and want to list one per line all within the cell for the contact name – sorry, no.
- Most banded report designers can import sub-reports – but only as a distinct completed report. They cannot be imported to become part of the main report being generated, using the live data populating the main report. This is a fundamental architectural limitation because of the concept of 1 table tied directly to a dataset.
- Most banded report designers do not support the concept of if or switch statements in the reports (and those that do have it for very limited use). If you wish to include formatted text at the bottom of an invoice based on the country, that can be very difficult.
- For some reason a lot of the banded report systems have trouble with paged output (i.e. to PDF). There's no fundamental reason why based on the concept of banding, but it appears that most place everything in the final report using absolute positioning as they build up the report, and that makes it difficult to then reformat for page breaks. Regardless, it's tends to be a problem.
- Banded reports strongly encourage you (for good reason) to create a stored procedure for the table in each report. This means any change in the report requiring additional data requires not just a change in the report template, but also in the underlying stored procedure. In many live systems changing a report template requires just minor acceptance testing but a change to the database, even if just a stored procedure, has a much larger effort to validate it before taking it live.
- The number of detail levels can be a problem, but most banded report designers allow 7 – 9 levels so this in practice is rarely an issue.
The beauty of free-form (as opposed to banded) report design is you can do anything you want. You select the data you need within the report, you iterate over any data, in any way, across any part of the template. You insert sub-reports as desired and they become part of the template populated with the data you are iterating over. You include charts, gauges, bitmaps, hyperlinks, etc. wherever under any criteria you wish. With free-form a detail sub-set can be any set of data you wish (even from another database) broken out over any part of the template you wish (not just rows). There is no such thing as a report header, table, and footer, there is just the template where you can place anything anywhere. With free-form, you can structure your report any way you can imagine.
For the cases where the strict structure of a banded report designer is difficult and/or limiting, please take a look at Windward Reports. With Windward you design your reports in Microsoft Word, Excel, or PowerPoint. It provides you a totally freeform report designer, both for layout and formatting. Wicked fast, extremely easy, and very powerful.
So next time you want to tear your hair out over the limitations or difficulity in your banded report designer, take a look at a freeform alternative. It will turn something difficult/impossible into something very easy.
