Entries in SSRS (2)

Saturday
29Aug2009

Top 5 reasons to use Linked Reports.

For those of you who have not explored the world of Linked Reports, I suggest that you do so.  Linked reports add a level of creativity and functionality to the world of SQLServer Reporting Services that must be explored and utilized if you are a serious reports developer. This post will highlight the reasons that I feel you, as a solutions developer, should start using Linked Reports.

  • Centralized Code...
    • With linked reports you can maintain a single set of base reports.  Instead of populating your reporting environment with multiple copies of the same report utilizing linked reports will allow you to maintain one version of each report in one location or folder.
  • One can be MANY...
    • You can use a base report but you can actually call it any name you want when you push that report out as a Linked Report. In the box above you can call the report anything you want if it is in a different folder than the base report. For one folder it may make sense to call it one name and for another it may make sense to call it another name.
  • Creative use of parameters can add to the flexibility.
    • Moving along the on same theme as the previous bullet, the creative use of parameters can help you when you roll out linked reports.  In addition to being able to change the report name of a linked report, utilizing different parameters for each linked report only adds to the flexibility. What we have done, in our implementation of linked reports, is modify the default values of the linked reports to make it a totally different report.  For example, maybe we have a report which will have a parameter called ReportType and there are two values to choose for that parameter. One value is Summary and the other option is Detailed.  When you run the report, if you choose Detailed it will give you the details of the data.  For the Summary version you get more of a rolled-up summarized view of the data.  With linked reports you can simply create two different linked reports where one is named Sales Order Transaction Summary and other is named Sales Order Transaction Detail.  The first linked report simply has a default value for ReportType of Summary and for the second report the default value is Detailed.  You then would hide that parameter to the user who is running it so that the user cannot change it.  So, what you have done is create two totally different linked reports from one base report.  I'm sure where you can see how creative you could get when it comes to base reports with many parameters.  One base report could end up being many different reports.
  • Rolling out schema changes is easy.
    • OK, you now have just received a new release of the database that all of your reports are running against.  With the centralized code base you now ONLY have to make the code changes to the base reports.  Once the changes are made to the base report and redeployed, any linked report that utilizes that base report should now reflect those changes.  One thing to remember is that if you do add new parameters to the base report you may have to make sure that the default values you have chosen in your linked reports stay the same.  I recommend testing in a test environment before you roll out code changes to your base reports in your production environment.
  • Linked report are fun!
    • I have to say that ever since we incorporated linked reports our whole team feels that this is certainly the way to go as far as deploying reports is concerned.  We also try our very best to develop multi-parameter, flexible base reports so that the ominous one-off report does not have to be developed.  We have found that if you are creative enough with the development of your base reports then you should be able to eliminate the dreaded one-off report. 

In conclusion, I implore you to start exploring and utilizing the use of Linked Reports.  I guarantee that you will enjoy them and you will be glad that you heeded my advice.

(Please feel free to leave comments on this post and let us know any creative ways you have used linked reports.)

Please subscribe to this blog using the RSS Feed link.

 

 

 

 

Saturday
11Jul2009

The "flexibility"of the Hidden property.

When I develop reports for end users one of my goals is to minimize the amount of reports that I have to develop and to make reports as "flexible" as possible.  One way that I have found that helps to minimize the amount of custom reports that I have to write is to creatively use the "Hidden" property to allow an end user to either hide columns or show columns on a report.  Under the category "Formatting Tips" in my SSRS Tips and Tricks FAQ, I want to focus on two entries. 

The first entry examines how easy it is to hide a column by simply adding a Boolean parameter to your report which represents the column you want to hide.  Since the Hidden property is already a Boolean or a true/false value, all you have to do is simply add the parameter in the expression editor next to the Hidden property.  In the example shown the "True" option is chosen and since the parameter is called HideProductNumber, then just placing the parameter into the Hidden property expression editor works perfectly. 

The next example adds a level of complexity as it utilizes a multi-value parameter to build a list of columns on the report.  If the user selects the column(s) this means that the column(s) will be hidden on the report.  It adds the "flexibility" that I was referring to above where one report could display completely different columns just by the choices of the end user.  When you think about this a little further you could add multiple sections to a report and allow the user to display any number of combinations of tables, charts, or matrices depending on the usage of the report. 

This property definitely adds a dynamic capability to a report that can be utilized in clever ways.  I would love to hear from others as to how you have creatively utilized the Hidden property in Reporting Services. I welcome your input...