Ten Common SQL Server Reporting Services Challenges and
Solutions
Many of us whohave to develop aReporting Services
(SSRS)application come across various problems, hurdles or
'gotchas' that cause much head-scratching. We've never seen,
elsewhere, the ten most common SSRS problemsever listed, let alone
their solution, but then along came Ryan with both.Help is now at
hand for anyone wrestling with Reporting Services. Indispensable
reading for any SSRS beginner.In every business there are several
different groups of report users, from chief executives, to
business analysts, to operational staff, who all need access to
reliable and current data in order to track overall business
performance, investigate the effectiveness of individual business
functions, or simply for ad-hoc day-to-day reporting.In most
organizations, at least some attempt has been made to meet these
reporting needs. Historically, however, the problem has been that
the available reports have not always been up-to-date, or even
accurate. Furthermore, individual departments have tended to adopt
a "silo" approach, using different tools/systems to create reports
that are useful within their silo, but not necessarily consistent
or compatible with those produced by other departments. In many
cases, there doesn't even exist a shared understanding of the
business data that underpin these reports.SQL Server Reporting
Services (SSRS), when it arrived, offered a much-needed means to
centralize and standardize reporting across the business, and it
has largely delivered. Having used SSRS 2005 for the past 4 years,
I've found that, with a little effort, it can satisfy most
business, ad-hoc, embedded, portal integration, web, and custom
reporting needs. However, I've also found that small "gotchas" can
halt progress and cause considerable frustration, as it's not
always easy to find ways round them in the documentation.In this
article, I round up some of the more interesting challenges that I
have encountered in my report development efforts, and the
solutions I've found to them. Hopefully, these will be useful to
the many (the majority?) people who are still using SSRS 2005 in
production. Some of the solutions offered can still be used in SSRS
2008. I conclude the article with a review of some of the issues
that SSRS 2008 has fixed, or at least
mitigated.Challenges/SolutionsSSRS offers a range of different
reporting techniques and technologies, to cater for the reporting
needs of all levels of users, from the chief executives, to
business analysts, to operational staff. Their reporting needs
range from simple, tabular ad-hoc reports, to parameterized, linked
or snapshot reports, to complex drill-down and drill-through
multi-level reports.Following is the list of some of the challenges
I have encountered while developing such reports using Reporting
Services 2000/2005. In the sections that follow, I will cover each
challenge individually, providing insight into what may cause the
difficulty, alongside a possible solution.1. Horizontal Tables:
Calendar Reports2. Select "ALL" Query Parameter option3. Multiple
Sheets in Excel4. Excel Merged Cell Issues5. Blank Pages6. Vertical
Text7. Report Data in Header/Footer8. Are you missing XML/CSV data
on your exports?9. Template Reports10. Using the Reporting Services
databaseA ZIP file containing samples of the reports detailed in
this article is availableto download, try out and amend to suit
your own needs.Horizontal Tables: Calendar ReportsThe most common
need for horizontal display of information, in my experience, is
for labeling or for calendar-style reports. There is no native
control that allows you to display your data horizontally. There
are a few different ways around this, but the easiest way I've
found is to use a Matrix control, which allows display of data in a
cross-tab or pivot format.The sample I will be using is of a
calendar style report, which will display a report of events which
occur in the timeframe displayed. You can build the report from
scratch using the steps that I'll outline next, or you can simply
import the completedCalendar.rdlfile, as part of sample project
proved in the code download for this article.The driving query for
this report is shown in Listing 1. The opening lines calculate the
required date range for the current month, which may include dates
from the prior and forthcoming months, in order to ensure that the
results display appropriately on the calendar.
TheStartDateparameter defines the first Sunday, and
theEndDateparameter the last Saturday, to display on the
calendar.The code then creates two Common Table Expressions (CTEs),
new to SQL Server 2005 and later. The first,Dates, generates a
record for every day in the required date range and the
second,Events, simply creates some sample event records for display
in the calendar.Finally, we query these two CTEs, using a ranking
function,DENSE_RANK, to assign number to the records based on the
date, and various date functions to generate the columns for the
matrix control (days of the week), days of the month, event details
and so on. The query in Listing 1 is self contained, so all you
need to do to test it out is point it to a SQL Server 2005 data
source.DECLARE@StartDateDATETIME,@EndDateDATETIME--First day of
current
monthSET@StartDate=DATEADD(s,0,DATEADD(mm,DATEDIFF(m,0,GETDATE()),0))--First
day to display on
calendarSET@StartDate=DATEADD(DAY,-DATEPART(WEEKDAY,@StartDate)+1,@StartDate)--Last
day of
monthSET@EndDate=DATEADD(s,-1,DATEADD(mm,DATEDIFF(m,0,GETDATE())+1,0))--Last
day to display on
calendarSET@EndDate=DATEADD(DAY,6-DATEPART(WEEKDAY,@EndDate),@EndDate);WITHDates([Date])AS(--Select
First day in rangeSELECTCONVERT(DATETIME,@StartDate)AS[Date]UNION
ALL--Add a record for every day in the
rangeSELECTDATEADD(DAY,1,[Date])FROMDatesWHEREDate
