Robert Bruckner's Advanced Reporting Services Blog : RS 2005

SharePoint Integrated Mode

Robert M. Bruckner — Fri, 21 Aug 2009 08:50:00 GMT

Chris Alton’s whitepaper on Reporting Services SharePoint Integration Troubleshooting is now available on MSDN. It provides a great set of configuration tips, diagnosis, and troubleshooting instructions.

The following two older Reporting Services 2005 SharePoint Integrated Mode related whitepapers are still available:

Enjoy!

Tablix – Multiple Subtotals Are Easy (aka Goodbye InScope)!

Robert M. Bruckner — Tue, 11 Aug 2009 08:45:00 GMT

Reporting Services 2005 with Matrix

In a matrix in Reporting Services 2005, accomplishing multiple or different subtotal calculations at the same grouping level was difficult, but possible. If you wanted to accomplish custom subtotal calculations in RS 2005, you may have heard about using the InScope function to dynamically determine the scope of a matrix cell at runtime. Let’s take a closer look at the following example with red numbers highlighting four different zones of the matrix to better understand the usecase:

1: Product category sales by each year. The matrix cell is within the scope of both, the ProdCat group as well as OrderYear group.
2: Product category sales aggregated across all years. The subtotal cell is within the scope of the ProdCat group, but outside the scope of the OrderYear group because it aggregates all years.
3: All product sales per each year. The subtotal cell is outside the scope of the ProdCat group (aggregating all products), but within the scope of the OrderYear group.
4: Overall grand total. The subtotal cell is outside both grouping scopes.

By default, the calculation defined in the matrix cell (1) in RS 2005 is performed the same way (but with different grouping scopes) in the subtotal cells (2, 3, 4).

There are however situation where for example, you want to calculate a running total of all product sales for each year (i.e. subtotal cell 3), and you want the average product category sales per year (i.e. subtotal cell 2). Or perhaps you only want drillthrough links to be active on individual matrix cells, but not on the subtotals.

To accomplish this in RS 2005, you would have to define the expression in the matrix cell using the following general pattern:

=iif(InScope("RowGroup"),
     iif(InScope("ColumnGroup"),
         "In Matrix Cell (1)",
         "In Subtotal of RowGroup (2)"),
     iif(InScope("ColumnGroup"),
         "In Subtotal of ColumnGroup (3)",
         "In Subtotal of entire Matrix (4)"))

Replace "In Matrix Cell (1)", "In Subtotal of RowGroup (2)", "In Subtotal of ColumnGroup (3)" and/or"In Subtotal of entire Matrix (4)" with the expressions or fields that you want.

Reporting Services 2008 with Tablix

With tablix in Reporting Services 2008, this scenario is significantly easier to accomplish. First, you get explicit cell definitions for each of those aggregation areas which removes the need for complex expressions and the usage of the InScope function:

In addition, you can define as many subtotals at every tablix grouping level as you like. For example, besides Sum(Sales), you could calculate a percentage of total revenue, or even year-over-year growth as shown in the following design surface screenshot.

The example above shows three different column subtotal calculations side-by-side under each OrderYear group instance:

Year Total
Year-over-Year growth percentage*
a KPI image that shows the growth trend (up/down/flat)*

Subtotals can use different styles as well as layout height or width. The example above also shows further aggregations such as the monthly trend shown as a nested sparkline chart*.

* Stay tuned - the underlying report, including RDL source, will be explained in an upcoming posting.

Subreport Usage

Robert M. Bruckner — Tue, 03 Mar 2009 17:40:00 GMT

In a previous post I showed how to quickly find reports that use custom report items (CRIs). The same idea can be applied to subreports as well. As an administrator of a report server, you may access the catalog database directly. Keep in mind that any queries you execute directly against the report server’s catalog database may affect the performance of the overall system. Make sure that you never take any locks on objects in that database, as this is not supported and interferes with the function of the report server.

The query below runs against the current version of the report server catalog database, and may not necessarily work for future RS versions. It uses XQuery and checks for all three different RDL namespaces since the catalog database stores a copy of the original report in exactly the format it was originally uploaded, so that (maybe several years) later, you can still retrieve exactly the report you published as a 2003/10 or 2005/01 report, even if it is internally on-the-fly upgraded to the latest schema version of the report server it is running on.

Use the following query to get a list of reports that reference subreports, including the path of those subreports:

USE ReportServer

/* declare and populate temp table */
DECLARE @tab TABLE (Path NVARCHAR(MAX), xmlColumn XML)
INSERT @tab
SELECT top 1500 Path, CONVERT(XML, CONVERT(VARBINARY(MAX), Content)) FROM Catalog WHERE Type=2;

/* find subreports in RS 2000-based main reports */
WITH XMLNAMESPACES ('http://schemas.microsoft.com/sqlserver/reporting/2003/10/reportdefinition' as rdl)
SELECT Path as ReportPath,
n.x.value('(//rdl:ReportName)[1]', 'nvarchar(256)') as ReferencedReport
FROM @tab
CROSS APPLY xmlColumn.nodes('//rdl:Subreport') n(x);

/* find subreports in RS 2005-based main reports */
WITH XMLNAMESPACES ('http://schemas.microsoft.com/sqlserver/reporting/2005/01/reportdefinition' as rdl)
SELECT Path as ReportPath,
n.x.value('(//rdl:ReportName)[1]', 'nvarchar(256)') as ReferencedReport
FROM @tab
CROSS APPLY xmlColumn.nodes('//rdl:Subreport') n(x);

/* find subreports in RS 2008-based main reports */
WITH XMLNAMESPACES ('http://schemas.microsoft.com/sqlserver/reporting/2008/01/reportdefinition' as rdl)
SELECT Path as ReportPath,
n.x.value('(//rdl:ReportName)[1]', 'nvarchar(256)') as ReferencedReport
FROM @tab
CROSS APPLY xmlColumn.nodes('//rdl:Subreport') n(x);

RS Tracer

Robert M. Bruckner — Tue, 24 Feb 2009 10:10:00 GMT

Have you ever wondered what API calls Report Manager or Management Studio are performing to accomplish certain operations?

Teo Lachev’s RsTracer helps answer these questions. The tool is available as a CodePlex project and shows the APIs that a Reporting Services client invokes and what arguments it passes to each interface. It also intercepts the server response. Armed with this information, you can easily reproduce the same feature in your custom management application. RsTracer works with all versions of Reporting Services.

The Ultimate Guide to Color Scales / Conditional Formatting

Robert M. Bruckner — Fri, 20 Feb 2009 09:35:00 GMT

I recently provided a tip to my Australian colleague David Lean to successfully solve a small report design challenge with tables and charts that use conditional formatting.

The specific goal was to dynamically calculate and assign a color shade so that the minimum value present in the data is shown red, the average value yellow, and the maximum value green, with automatically calculated red-yellow-green shades for numeric values in between.

As it turns out, Dave integrated and expanded this into a great four part blog post series on using conditional formatting and color scales in Reporting Services (applicable to both, RS 2005 and RS 2008):

Enjoy!

BIDS Helper, RS Scripter

Robert M. Bruckner — Wed, 28 Jan 2009 20:15:00 GMT

I wanted to point out two Reporting Services utilities built by our MVPs and user community that you may find very useful.

BIDS Helper is a CodePlex project: http://www.codeplex.com/bidshelper

In past releases, the focus has been on significantly enhancing Analysis Services and Integration Services BIDS design experiences. Version 1.4 was just released, and for the first time BIDS Helper now also includes small Report Designer enhancements:
- identifying unused datasets in the report (by removing them you may speed up your report)
- deleting dataset cache files (.rdl.data) directly from within BIDS

RS Scripter is a utility for scripting and managing report server catalog items: http://www.sqldbatips.com/showarticle.asp?ID=62

You might find RS Scripter particularly useful for:
- quickly and easily extracting all RDLs from a report server
- generating scripts to load reports, data sources
- script shared schedules, subscriptions, system and item level roles
- migrating contents from one report server to another

Report Server Optimizations

Robert M. Bruckner — Wed, 14 Jan 2009 22:40:00 GMT

The fourth and final technical note "Reporting Services Performance Optimizations" in our series on Building and Deploying Large Scale SQL Server Reporting Services Environments is now available on SQLCAT.com.

The focus of this final technical note is on how to optimize your Reporting Services architecture for better performance and higher report execution throughput and user loads.

Optimizing Reports - Show the Right Set of Data

Robert M. Bruckner — Tue, 13 Jan 2009 10:00:00 GMT

You are probably now thinking, of course my report shows the right data!

Ok, but is it fast (enough)?

My esteemed colleague Dean Kalanquin started blogging recently. He has been working in databases for a long time, and has gained great experience and knowledge by working on several different areas of SQL Server before joining the Reporting Services team a few years ago. Among our common interests are certainly performance and scalability. While Dean and I typically approach these areas in similar ways, Dean tends to focus more on the database side of things, and I leverage my knowledge about the internals of the report processing engine to look at it also from a report design and data processing point of view. Together, we regularly figure out great ways to effectively optimize systems and reports.

In his first technical blog post titled "Pet Peeve: Slow Reports", Dean provides tips on how to optimize reports by applying pre-aggregation already in the database query and only returning data you really want to show upfront. Further detail data can then be provided as drillthrough reports that only retrieve a specific subset of the original data, or you could apply a combination of drill-down + drillthrough, as discussed in a recent posting.

I think Dean is going to be doing a whole series on various report design and optimization "gotchas", so his blog is definitely worth keeping an eye on.

Report Performance Optimization Tips (Subreports, Drilldown)

Robert M. Bruckner — Fri, 09 Jan 2009 10:25:00 GMT

In a previous posting, I explained the new ExecutionLog2 view in Reporting Services 2008: how to utilize it to measure report execution performance, identify report candidates for optimizations, and verify the impact of the latter. I also included two tips at the bottom of that posting, that I want to call out explicitly as a separate posting.

Subreports

One of the aspects I usually investigate when optimizing reports is the usage of subreports. Subreports provide a convenient way to reuse report designs, but it may make sense to refactor the report design to lift the subreports contents into the main report. Not only does this frequently result in improved performance, it can also provide better control over rendering behavior.

Btw, this related blog posting explains how one can quickly find out which published reports reference subreports.

Splitting large drilldown reports into parameterized drillthrough reports

When reports use large datasets, I have sometimes seen the usage of drilldown group hierarchies (toggles) to provide an initial overview to the report consumer, and enable dynamic drilldown to interesting areas.

What may work really well for those kind of reports is to change the original report to only include data till e.g. the third level of drilldown (and thereby reduce the amount of data retrieved and processed by the initial report, and improve response time).

Then at the innermost drilldown level of the main report, create drillthrough actions with parameters based on the current group values to another report. The drillthrough target report provides further details and drilldown capabilities, but only has to retrieve a small subset of the original data.

What Kind of Reports are Published / Which Use Custom Report Items?

Robert M. Bruckner — Fri, 09 Jan 2009 10:15:00 GMT

As an administrator of a report server, you may occasionally ask yourself the question of what kind of reports are published in terms of their particular feature usage. For example:

· Usage of Custom Report Items (CRIs)
You plan to upgrade from RS 2005 to RS 2008 and there are CRI controls installed on your current RS 2005 server (look for a <ReportItems> section in rsReportServer.config)? You may want to know whether they are actually referenced in any currently published reports on the server, because you may have read this related blog posting and are wondering if you need to install the 2005-based CRI controls on your RS 2008 server?

· Usage of subreports
Which reports use subreports? Not only is this interesting for dependency tracking, but it might also be relevant for optimizing performance.

· Usage of custom assemblies
What kind of (custom) assemblies are referenced by published reports? This might be interesting information for auditing, or for trouble-shooting the security policy configuration of a report server.

Offline Solutions

Well, as always there are multiple ways to accomplish this.

One option is to download all the reports from the server in an automated way and then analyze the RDL contents. This can be accomplished similar to the RS Explorer sample application, via the Reporting Services SOAP API, and using ListChildren and GetReportDefinition. Alternatively, you could utilize RS Scripter, a great tool written by Jasper Smith, to script/download all reports. For the subsequent offline analysis in the file system use full text search tools (e.g. findstr).

Basic SQL Query Solutions

As an administrator of a report server, you may access the catalog database directly. Keep in mind that any queries you execute directly against the report server’s catalog database may affect the performance of the overall system. Make sure that you never take any locks on objects in that database, as this is not supported and interferes with the function of the report server. That said, if you are familiar with the RDL XSD structure, you can write a simple query like the following to find all reports that reference subreports:

USE ReportServer

SELECT Path, Name, Description, *

FROM Catalog

WHERE Type = 2 AND

CONVERT(VARCHAR(MAX),CONVERT(VARBINARY(MAX),Content)) LIKE '%<Subreport%'

SQL XQuery Solutions

Let's now focus on a slightly more complex scenario: you want to determine which types of CRIs are used by which reports on your server.

Note that the RDLs stored in the report server are exactly the RDL files that were originally uploaded. Since the CRI feature was introduced with the RDL 2005/01 namespace, we only need to query that particular namespace to find reports that reference 2005 CRIs. If however you are looking for subreports or other elements, you may have to query several namespaces: RDL 2003/10, RDL 2005/01, and RDL 2008/01. Btw, my esteemed colleague John Gallardo used to work a lot with XQuery before joining the Reporting Services team and helped crafting the initial query, which I further refined to this:

USE ReportServer

/* declare and populate temp table */

DECLARE @tab TABLE (Path NVARCHAR(MAX), xmlColumn XML)

INSERT @tab

SELECT Path, CONVERT(XML, CONVERT(VARBINARY(MAX), Content)) FROM Catalog WHERE Type=2;

/* for all CustomReportItem elements, display the report path, CRI type and name */

WITH XMLNAMESPACES ('http://schemas.microsoft.com/sqlserver/reporting/2005/01/reportdefinition' as rdl)

SELECT Path as ReportPath,

n.x.value('@Name', 'nvarchar(256)') as CRIName,

n.x.value('(//rdl:Type)[1]', 'nvarchar(256)') as CRIType

FROM @tab

CROSS APPLY xmlColumn.nodes('//rdl:CustomReportItem') n(x)

Using Teradata's .NET Data Provider

Robert M. Bruckner — Sat, 27 Dec 2008 04:00:00 GMT

Reporting Services 2008

RS 2008 includes full support for Teradata-based report models. You can create and use semantic models based off Teradata similar to how Reporting Services already supports this for SQL Server, Analysis Services, and Oracle. Furthermore, RS 2008 includes a Teradata data extension directly in the box. Among other features, that data extension provides full support for multi-valued query parameters in Teradata queries.

The only step left for you is to download and install Teradata's .NET Data Provider for Teradata 12.0. No further configuration step is needed for RS 2008.

Finally, I recommend to read the following whitepaper on using Teradata connectivity in Reporting Services.

Reporting Services 2005 SP3

With the recent release of Service Pack 3 for SQL Server 2005, we include the same level of report model / semantic query support for Teradata that we provide in Reporting Services 2008. Furthermore, the Teradata data extension is included as well.

Before you can use this new functionality in SP3 however, manual steps are necessary to turn it on after the installation of SP3, and Teradata's .NET data provider. The manual steps are explained in detail in the updated SQL Server 2005 Books Online documentation, and in the MSDN online help page for "Configuring Reporting Services for Teradata-based Report Models".

Registering Teradata's .NET Data Provider directly
(without data extension)

If you are on RS 2005 SP2 or lower, I highly recommend to upgrade to RS 2005 SP3 or RS 2008 - you will get built-in support for Teradata-based report models, and Teradata connectivity with extended features such multi-value parameters.

However, if you aren't ready to upgrade quite yet, you still have the option of using direct Teradata data connectivity by manually registering the data provider directly in RSReportDesigner.config and RSReportServer.config. This provides the ability to define and execute queries against Teradata data sources. However, this does not provide support for any of the extended data features in Reporting Services such as multi-valued query parameters (please see this documentation link for more details on the differences).

Steps for manual registration of Teradata's data provider with Reporting Services:

Report Server:

Install Teradata's .NET Data Provider for Teradata 12.0
Open RSReportServer.config.
For RS 2005 installations, by default this file is located in <SysDrive>:\Program Files\Microsoft SQL Server\MSSQL.n\Reporting Services\ReportServer.
In the <Data> section, add the following entry. This entry must be on one line with no line breaks; the version stamp must match the version number of the provider you installed:
<Extension Name="Teradata" Type="Teradata.Client.Provider.TdConnection,Teradata.Client.Provider, Version=12.0.1.0, Culture=neutral, PublicKeyToken=76b417ee2e04956c"/>
Save the file and then restart Reporting Services on the report server. For more information, see Starting and Stopping the Report Server Windows Service.

Report Designer in BI Development Studio:

Install Teradata's .NET Data Provider for Teradata 12.0
Open RSReportDesigner.config.
For RS 2005 installations, by default this file is located in <SysDrive>:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies
In the <Data> section, add the same entry as above for the report server:
<Extension Name="Teradata" Type="Teradata.Client.Provider.TdConnection,Teradata.Client.Provider, Version=12.0.1.0, Culture=neutral, PublicKeyToken=76b417ee2e04956c"/>
In the <Designer> section, add the following entry. This entry must be on one line with no line breaks.
<Extension Name="Teradata" Type="Microsoft.ReportingServices.QueryDesigners.GenericQueryDesigner, Microsoft.ReportingServices.QueryDesigners"/>
Save the file.

Btw, besides the managed provider, Reporting Services also works with Teradata's ODBC and OLEDB data providers. Those don't need any particular RS config file registrations, as they are supported via the generic ODBC and OLEDB data extension by Reporting Services.

Enjoy!

Technical Note Series on Reporting Services Performance and Scalability

Robert M. Bruckner — Tue, 04 Nov 2008 08:40:00 GMT

Over the past few months, I contributed to a series of technical notes by my esteemed colleagues Denny and Lukasz on http://sqlcat.com/. The technical notes provide guidance on how to build, deploy, and optimize large scale SQL Server Reporting Services (SSRS) environments. We derived some of the best practices from internal as well as external enterprise SSRS deployments.

So far, a webcast and three technical notes are available; we are working on (at least) one more. The notes apply to both SQL Server Reporting Services 2005 and 2008, unless a particular section calls out one of the releases explicitly.

New: TechNet Webcast
Webcast summarizing the material of all four technical notes below.
Reporting Services Scale-Out Architecture
The focus of the technical note is an overview of the Reporting Services scale-out architecture, referenced throughout the technical note series.
Report Catalog Best Practices
Provides guidance and best practices on the report server catalog databases; i.e. the underlying databases that provide metadata (parameters, snapshots, history, etc.) used by Reporting Services to provide your reports.
Scale-Out Deployment Best Practices
Provides guidance and best practices on deployment details for scaling out your Reporting Services environment including configurations and the use of File System snapshots.
New: Reporting Services Performance Optimizations
This fourth technical note focuses on general considerations for optimizing your entire system.

In addition, I put together a blog post about the ExecutionLog2 view which provides insights into analyzing and optimizing reports. This is related to what I covered in my very well received CT-27 chalk talk at the Microsoft Business Intelligence Conference recently on "Report Design Tips, Tricks, and Best Practices for Performance and Scalability". I might put together additional postings to cover more of that information - check my postings marked with the "Performance" and/or "Scalability" tags frequently.

Related to these topics, I'd also like to point to one of my initial postings about scale up improvements in Reporting Services 2008.

Do You ▖ Unicode in PDF?

Robert M. Bruckner — Tue, 28 Oct 2008 06:20:00 GMT

One of the changes we included in Cumulative Update #1 for SQL Server 2008 (CU1 download link) is automatic full font embedding and subsetting for Unicode characters in Reporting Services 2008 PDF rendering.

While a similar code change is now available for Reporting Services 2005 PDF rendering with SQL Server 2005 Service Pack 3 (SP3 download link), it is not full font embedding like RS 2008. Specifically, in RS 2005 if your text contains Latin characters only, no font embedding is happening. The font embedding in RS 2005 SP3 is limited to non ANSI characters.

Overall, with font embedding it does no longer matter what version of a font is installed on a client - the documents can be viewed the same way regardless of client operating systems, font versions, and client PDF viewer. Generating multi-lingual reports and using fonts such as MingLiU just got a little bit easier.

What DataSet Query Text Is Executed?

Robert M. Bruckner — Sat, 25 Oct 2008 22:15:00 GMT

In a previous posting, I discussed dataset execution order in Reporting Services. In this posting, I will provide a few tips for situations where you or your report users are wondering what is the actual query executed by Reporting Services.

While you can accurately answer this question using a profiler connected to the data source machines or in some cases by opening the dataset properties dialog, there are other options directly available from within reports. You will probably encounter the following main situations:

Parameterized or regular datasets
In order to see the underlying query command text in the report, add a textbox with the following RDL expression, utilizing the built-in DataSets collection and the CommandText property. This can be particularly useful when you use an expression-based query command text, as the CommandText property will contain the evaluated expression result.
=DataSets!DataSetName.CommandText

If you use report parameters bound to query parameters in your dataset, you can display those values by accessing the built-in Parameters collection. For example, assuming P1 is a multi-valued report parameter, we utilize the Join function to show the current parameter values as comma-separated list:
="P1's values: " & Join(Parameters!P1.Value, ", ")
Report Model based datasets
Using Report Builder 2.0 with a shared data source on your report server that points to an existing report model is a very powerful combination. It enables users to create quite complex queries easily that would be rather difficult to write as actual SQL or MDX queries. Similar to above, you can use the RewrittenCommandText property to get the model-based query with parameter values rewritten as literals:
=DataSets!DataSetName.RewrittenCommandText

You can make this more sophisticated by only dynamically showing the query text in the report, e.g. based on a parameter or by toggling the visibility using another textbox:

More information about all built-in global collections accessible from RDL expressions is available in SQL Server Books On Line. Note that some of the server related properties don't have values in local preview, only when connected to a server in Report Builder 1.0 / 2.0 or running directly on a server.

The CommandText property value always represents the original command text as defined in the RDL dataset. The RewrittenCommandText property value is populated at runtime from data extensions that support the IDbCommandRewriter interface. This interface allows Reporting Services to read the CommandText back from the data extension after it has merged the original command text and parameter values. If a data extension doesn't support this interface, RewrittenCommandText will be null/Nothing. Currently the built-in report model data source supports this interface, although it could also be implemented by any custom data extension.

Using Analysis Services Parent-Child Hierarchies in Reports

Robert M. Bruckner — Wed, 15 Oct 2008 08:45:00 GMT

One of the questions that I answer somewhat frequently, is about recursive groupings in Reporting Services and how to utilize parent-child hierarchies from an Analysis Services cube.

The attachment of this posting contains a small report example I put together based on the Analysis Services 2005 Adventure Works DW sample cube, and demonstrates a recursive hierarchy using the employee dimension. It works both in Reporting Services 2005 and 2008. Partial screenshot of the attached sample report output:

Particular areas to note / steps:

The table group is defined as a recursive grouping based on the UniqueName and ParentUniqueName property values from the Analysis Services parent-child hierarchy. Consequently, there is only one group defined at design time, that automatically expands recursively at runtime based on the parent-child hierarchy in the cube.
Group expression: =Fields!Employees.UniqueName
Parent group expression: =Fields!Employees.ParentUniqueName
Group visibility is toggled by the textbox within the group, to enable automatic drilldown along the parent-child hierarchy.
In the example, manager names in the employee hierarchy (i.e. they have at least one employee reporting to them) are shown in bold font. This is accomplished with a count aggregate function that takes into account the full recursive hierarchy of all children by explicitly specifying the Recursive keyword as third argument. The textbox FontStyle property is set to the following RDL expression:
=iif(Count(Fields!Employees.Value, "table1_Details_Group", Recursive) > 1, "Bold", "Normal")
The textbox showing the employee name uses dynamic left padding (in RS 2008 paragraph indents can be used as well) based on the current recursive hierarchy level using the Level() function.
For example: =20 * Level() & "pt"

Recursive hierarchies can also be very useful for relational data sources, not just parent-child hierarchies in cubes. I hope the explanations in this posting and the attached sample report resolve some of the mystery around parent-child / recursive hierarchies, and using regular vs. recursive aggregate functions. Enjoy!