5 things I wish every SSRS developer would do

James Luetkehoelter — Tue, 26 Feb 2008 10:34:00 GMT

I had a great discussion while teaching a class on Reporting Services today, discussing the basics of report design (yes, I make them consider basic principles of report design before I start talking about the technical details - I'm a stickler that way). That made me consider some of the most common design issues that I see with SSRS and the principles I'd like to see everyone stick to:

1) Design for your audience - If you develop a report that is more than one page and give it to a CEO or upper management, it will probably be ignored. If you give a one page report to a "bean-counter", they'll throw it away (and yell at you to boot). One of the hardest aspects of report design is determining the level of detail for any given audience.

2) Design for design - This is an odd phrase, but the whole concept of getting all of your report requirements up front, spending a fair amount of time developing the report, only to have the end user say "that isn't what I wanted". Often you can't get sufficient requirements from your customers without presenting them with a sample report and asking them if it accurate (data) and what they wanted (layout). That first pass through in report design should be simply to find out what the customer really wants. How often do customers ask for what they really want?

3) Design for reuse - No report should be a complete standalone. It may begin that way, but there should always be the opportunity to either expand on the original design or leverage it using different parameters. Rather than making a single report for a single department, investigate creating a general report that any department could use, then make it specific for that single department by means of a hidden parameter. If you combine that type of general report with the functionality of linked reports, you can have distinct, visual and securable reports all driven from the same design. Think about reusability from the very beginning - you'll be surprised how often it pays off.

4) Design with pagination in mind - In particular with parameterized reports, you need to be aware of how SSRS will handle pagination. Since we can set pagination rules with each individual data region, those including multiple regions (read: a list within a list within a list ad infinitum), pagination can quickly get out of control. Side by side data regions are even worse. What you thought would be a single page report can often grow into a multi-page report, page-breaking in the most awkward of places. Be sure to control your pagination (hint: ever explore the Rectangle quasi-data region?).

5) Design as if you aren't writing a report - SSRS gives you the ability to display marginally related data (from a database standpoint) together on the same report by means of separate data regions. Other reporting tools traditionally use a banded design: a detail row, grouping rows, report headers and footers, etc. SSRS presents us with a canvas to paint a variety of report display items from separate data sources (without subreports - no one should ever have to use a supreport again). Take advantage of that ability and fundamentally rethink what the best way to visualize data.

If you disagree, tell me why. If you want me to blather on more about a specific item, just let me know (those that know me well know that once you get me started, I'm off to the races - viva la propeller-heads!).

James Luetkehoelter : SSRS

5 things I wish every SSRS developer would do