THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

James Luetkehoelter

Nearly any SQL topic presented at times in a slightly eclectic manner.

5 things I wish every SSRS developer would do

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!).

Published Tuesday, February 26, 2008 5:34 AM by James Luetkehoelter

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

andyleonard said:

Hi James,

  I think your only mistake is in limiting these concepts to SSRS development. These are clearly principles of software design that can (and should) be applied to all projects.

:{> Andy

February 26, 2008 11:32 AM
 

Geoff said:

I'm trying to think of another way of saying 2). Having something tangible to critique is really important when developing GUIs. There is always something unverbalized or something which will not be recognized until the actual product is before you.

February 26, 2008 11:57 AM
 

James Luetkehoelter said:

Andy: I totally, totally agree. Report design should follow basic UI principles (limit information to one screen, don't overload with info, etc.). I only wanted to complain about report design for now - I'll pick on UI design at another time (and don't get me started there :) ).

Geoff: That's a great way to put it - your first round through a UI design (which is what a report is) should be to give the customer an idea of what they could have, or present them with what they asked for so they can realize that they were mistaken in what they needed (or misworded it). Unverbalized - that's the problem, isn't it - there are some things you just can't verbalize unless you have a hint of some kind...great response, thanks!

February 26, 2008 12:26 PM
 

Hans Mustermann said:

Pagination in RS is awful.

You can't even use expressions to control it.

Also, when exporting to certain formats, the whole thing gets screwed up anyway.

March 3, 2008 3:44 AM
 

James Luetkehoelter said:

Hi Hans,

I agree that paginition is a pain. I'm going to be a little more kind and call it "challenging". There are things that can be done control it (mostly using Lists and Rectangles), but even then there can be odd pages. Exporting controlled or uncontrolled pagination can also lead to "interesting" results.

So, in the mindset of my original post, I would as this as something developers need to take in mind from step one - how will it paginate? And how will it paginate when exported to say, PDF?

Great point, pagination is another one of those basic UI design principles that you see missed time and time again. Thanks!

March 3, 2008 10:52 AM
 

SSRS Guy said:

RE: "(without subreports - no one should ever have to use a supreport again)"

Take the situation where your report needs to call a Stored Procedure to populate its report table, before reading the data from said table.

How would you go about doing this without using a sub-report as the data reader?  There appears to be noway to control the order SP's are called within a single (non-subreport) report.

I have been told the only way to do this in SSRS (Report Builder) is with subreports.

July 2, 2008 12:58 AM
 

Prasanna KJ said:

Hi can Anyone help me Regarding the alternate point labels  in chart

please do reply

August 29, 2008 3:53 AM
 

snktheone said:

Hi James ,

Nice blog ...

appreciate your suggestions on the best practices...

All those who are still lost with the basics on SSRS

check out my blog @

http://ssrsbasics.blogspot.com/

October 1, 2008 4:04 PM
 

Chan said:

Hi James,

 Thanks for tips. I am write about a SSRS blog as well. If anyone is intested go to http://ssrsdeveloper.blogspot.com/

Thanks.

January 20, 2011 5:44 PM
 

Boris_Us said:

Hi James,

This is not only reporting tool, you can analyse your data results

April 3, 2011 11:40 AM

Leave a Comment

(required) 
(required) 
Submit

About James Luetkehoelter

I am passionate about what I do - which is DBA, development, IT and IT business consulting. If you don't know me, haven't met me or have never heard me speak, I'm a little on the eccentric side. One attendee recently described me as being "over the top". Yup, that about says it - because I only speak on topics that I'm passionate about.
Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement