Bob's SQL Reporting Services Blog : Report Builder

Add Excel-like "color scale" conditional formatting to your reports

bobmeyers — Sat, 01 Aug 2009 03:09:00 GMT

I’ve been meaning to do this for a long time, and it looks like David Lean beat me to it earlier this year by posting an incredibly thorough four-part discussion of how to do conditional formatting in Reporting Services. I’ve played with his sample code a bit and put together a variation on his theme that meets some additional requirements, which I have found helpful.

The attached sample code is designed to provide the following functionality (the usual disclaimers apply):

· Convenient support for the standard color scales available in Excel 2007

· Support for arbitrary colors, including named colors (“MintCream”)

· Robust handling of null, error, and out-of-range values

· Robust handling of all integral and floating point numeric types

To use them in a report, do the following:

1. Open the Report Properties dialog (right-click on the space around the report body, choose Report Properties)

2. On the Code page, paste in the attached code

3. On the References page, add a reference, click Browse, locate and select System.Drawing.dll, usually in C:\Windows\Microsoft.NET\Framework\v2.0.50727 (this references allows the code to handle named colors)

The simplest and most common usage of these functions is to create a red-yellow-green “heat map” based on the value being displayed in the text box. This is done by setting the text box’s Fill color to an expression similar to the following:

=Code.ColorScaleRYG(Sum(Fields!SalesAmount.Value), 0, 100000)

The arguments 0 and 100000 are the min and max values for the color scale. In this case, the ColorScaleRYG function is used, which assigns red to the low value, green to the high value, and yellow to the value half-way in between.

The min and max values can also be calculated, like this:

=Code.ColorScaleRYG(Sum(Fields!SalesAmount.Value), Min(Fields!SalesAmount.Value, “Dataset1”), Max(Fields!SalesAmount.Value), “Dataset1”))

The argument “Dataset1” defines the scope in which the min or max value is calculated, which must be a parent scope of the current scope.

Note that these colors are not the pure “Red”, “Green”, and “Yellow” colors defined in HTML/.NET/SSRS, but rather the default values used in Excel which are intended to provide a reasonable background for black text. If you don’t like them, it’s easy to specify your own colors instead.

Here’s a full list of the functions provided:

‘ Convenience functions for standard 3-color scales

public function ColorScaleRYG(value, minValue, maxValue) as string

public function ColorScaleGYR(value, minValue, maxValue) as string

public function ColorScaleRYB(value, minValue, maxValue) as string

public function ColorScaleBYR(value, minValue, maxValue) as string

public function ColorScaleRWB(value, minValue, maxValue) as string

public function ColorScaleBWR(value, minValue, maxValue) as string

‘ Convenience functions for standard 2-color scales

public function ColorScaleRY(value, minValue, maxValue) as string

public function ColorScaleYR(value, minValue, maxValue) as string

public function ColorScaleGY(value, minValue, maxValue) as string

public function ColorScaleYG(value, minValue, maxValue) as string

‘ Arbitrary 3-color scale with interpolated midpoint value

public function ColorScale3(value as object, minValue as object, minColor as string, midColor as string, maxValue as object, maxColor as string) as string

‘ Arbitrary 3-color scale with explicit midpoint value

public function ColorScale3(value as object, minValue as object, minColor as string, midValue as object, midColor as string, maxValue as object, maxColor as string) as string

‘ Arbitrary 2-color scale with optional error color (the core function)

public function ColorScale(value as object, minValue as object, minColor as string, maxValue as object, maxColor as string, optional errorColor as string = "Transparent") as string

Enjoy!

SQL Server 2008 SP1 available now with important Report Builder 2.0 updates

bobmeyers — Wed, 08 Apr 2009 08:28:00 GMT

SQL Server 2008 SP1 is now available, and includes some important updates related to Report Builder 2.0:

- RB 2.0 can now be deployed directly from the report server using ClickOnce. You can also configure whether RB 1.0 or RB 2.0 is launched from the Report Manager and SharePoint UI.

- An important fix to the Report Model Query Designer is included in SP1.

Download SQL Server 2008 SP1

Download Report Builder 2.0 (April 2009)

Help RB 2.0 users find and use shared data sources

bobmeyers — Sat, 28 Mar 2009 07:26:00 GMT

Report Builder 2.0 makes it easy for business users to browse for and use centrally-defined and managed data sources. It does this by supporting direct connection to a report server as part of the design experience. It also maintains a list of recently-used data sources that show up at the top of the list each time the user needs to create a new connection in their report. One problem, though, is how to help RB 2.0 users find published shared data sources in the first place.

You can do two things as an administrator to make this easy:

1. Configure RB 2.0 on each client machine with a default report server. This can be done from within the app (see Options->Settings), or pre-emptively at install time by passing the REPORTSERVERURL command-line argument to the RB 2.0 installer (more info). Note that if you are using SMS, this can be done automatically as part of pushing the software out to the client.

2. Set default folder properties on the report server. RB 2.0 looks for two properties on the Report Server that tell it where to find shared data sources and models. If RB has a default report server, and these two properties are set on that server, any data sources or models that RB finds in those folders will automatically show up in the data sources list, in addition to any recently-used data sources. Use the attached scripts and the RS Script Utility to view or set these properties (instructions are in the script). Once the properties are defined, they can also be viewed and modified in SQL Server Management Studio, under Server Properties->Advanced->User Defined.

UPDATE: Adding missing attachment. :)

What is that extra column of 'AB.gAAAA=' values when I run a report model query?

bobmeyers — Fri, 06 Mar 2009 20:36:00 GMT

Most people using Report Builder 2.0 with a report model soon ask the question, what is that extra column I get back with strange values like “AC8AAAA=” in it?

Answer: It's an entity key value. If you’re going to create a group on that entity in your report, you should use this field as the group expression. This is especially important if you’re going to create Clickthrough links, because those key values will be used to filter the target report, and filters on keys usually have better performance.

How to build a Clickthrough link in Report Builder 2.0

bobmeyers — Thu, 05 Mar 2009 18:45:00 GMT

As I mentioned in a previous post, due to resource constraints in this release, Report Builder 2.0 is not a strict superset of RB 2005/1.0. One of the features missing from RB 2.0 is automatic creation of Clickthrough links. You can still get them, of course, by creating the basics of your report in RB 1.0, then saving and reopening in RB 2.0. It is also possible to build them manually.

Here's how:

1. Determine what the target entity should be. This is the model entity the Clickthrough link should drill to. For example, if the value being displayed is # Sales Orders, you'll want to drill to the Sales Orders entity.

2. Get the target entity ID. (This is the worst part) Unfortunately, this value is not accessible from within RB 2.0. You can see it in the property grid in Model Designer, or you can get someone who has the RS Script Utility to use the attached script to get a list of all the entity IDs in the model. Keep the list around for reference.

3. Determine whether to show a single-instance or multiple-instance report. If the path from the value’s context to the target entity involves at least one “one-to-many” relationship, then the drill action can return multiple instances of the target entity, so you’ll need to show a multiple-instance report. Remember that the path from a report subtotal to the target entity is always one-to-many. Only use a single-instance report if there are no one-to-many relationships along the path. For example, if the value being displayed is # Sales Orders per Sales Territory, the value’s context is Sales Territory, and the path from that context to the target entity is Sales Territory -> Sales Person -> Sales Orders. Both of those relationships are one-to-many, so this Clickthrough action should use a multiple-instance report.

4. Create a "Go to report" action. Open the property dialog for the Text Box, Placeholder, Chart Series, or other report element that has Action properties, and go to the Action property page. Select the “Go to report” option and use the following settings:

Setting	Value
Report Path	=DataSources!MyDataSource.DataSourceReference
Parameters	Value
rs:EntityID	(Target entity ID)
rs:DrillType	“Detail” or “List” for single- or multiple-instance, respectively
rs:Command	“Drillthrough”
DrillthroughSourceQuery	=Datasets!MyDataset.RewrittenCommandText
DrillthroughContext	=CreateDrillthroughContext()

A few tips:

· Clickthrough links will not work correctly in a “details” scope, i.e. a group with no grouping expression. If you want to use them in a scope that is currently a details scope, you’ll have to change it to a non-details scope by adding one or more grouping expressions that uniquely identify each row of data.

· If the value you are displaying is an expression that involves multiple field references, set the target entity as the entity at the end of the longest common path between them.

· Read up on how creating customized Clickthrough reports can help maximize the value of every Clickthrough link you create.

Report Builder 2.0: Whither report models?

bobmeyers — Thu, 05 Mar 2009 17:46:00 GMT

Just a quick post to answer the inevitable question when those familiar with Report Builder 2005/1.0 start playing with Report Builder 2.0:

Whither report models?

The short answer is that they are still available as a data source type, and the report model query designer is included as well, so you can create datasets against them just like any other data source. The part that's missing, obviously, is the ability to build the report layout and the query at the same time by dragging data from the model directly on to the layout surface, as in RB 1.0 (we called this "integrated query design"). The reason for this limitation in RB 2.0 is simply limited resources. There was so much demand for a more full-featured standalone report authoring application, including full layout capabilities and support for many data source types, that we did not have time to recreate the same "integrated query design" experience in a completely overhauled and much more (internally) complex layout editor. Because we were unable in the SQL 2008 timeframe to make RB 2.0 a complete superset of the RB 2005/1.0 experience, we chose to re-ship RB 1.0 in that release (with some minor updates) for those who preferred an RB 1.0-like solution for now.

Rest assured, though, that we are hard at work on closing the gap as soon as possible. We are also working on a number of exciting and valuable enhancements to report models and report model queries that will enable new scenarios while making the query design experience even easier.

Sorting the values in parameter dropdowns in Report Builder

bobmeyers — Thu, 11 Oct 2007 11:44:00 GMT

In SQL 2005 the semantic queries generated by Report Builder do not support sorting. This is not a problem in the report itself, because all sorting is defined and implemented in the report definition instead of the query. However, for parameter dropdowns there is currently no solution: if the query doesn't sort the data, there's no way in RDL to define the sort you want. As a result, the values in your parameter dropdowns will sometimes be scrambled.

If you are interested, the attached C# project contains an updated version of the custom data processing extension I shared in a previous post for enforcing query timeouts, This version adds the ability to recognize lookup queries generated by Report Builder (e.g. those generated for parameter dropdowns), and append an appropriate ORDER BY clause to get the data back in the right order. Since the order of the result data is not defined in this release, it should not break anything, and since it uses a very strict Regex to recognize the lookup queries, it should not affect performance of any other queries. This implementation will sort dropdown items in exactly the same order as they appear in the Filter dialog in Report Builder, whether they are attribute values or entity instances (including the use of an entity's SortAttributes if defined).

To try out the sample, download the attached ZIP file and follow the same instructions as before, Please note that, as I mentioned before, this approach exercises an unsupported feature, so if you run into problems and ask MS Support for help, they will tell you to go jump in a lake. :)

Requiring Report Builder users to choose a perspective

bobmeyers — Tue, 27 Feb 2007 22:28:00 GMT

Some customers have report models that are large enough they do not expect any user to ever request the entire model, and would actually prefer to disallow that option, and require them to choose a perspective instead. There is an undocumented and unsupported feature that provides this behavior in the current release. It is used by Analysis Services when generating a report model over a cube.

The simplest approach is to use the SOAP API's to add a custom property to the report model with name = "MustUsePerspective" and value = "true".

If you wish, you can add a similar custom property to the report model within Model Designer, set the property data type to Boolean, set the namespace to "http://schemas.microsoft.com/sqlserver/2004/11/semanticquerydesign", and whenever you publish the model the corresponding server property will be added automatically.

Launching Report Builder from the command line

bobmeyers — Fri, 23 Feb 2007 03:04:00 GMT

A number of people have asked if it is possible to launch RB from the command line. While it is in fact possible, it is an unsupported feature in SQL Server 2005. That said, here's how to do it. You just need to specify what report server to connect to, like this:

ReportBuilder.exe /s=http://mybox/reportserver

Other supported URL parameters are also recognized when passed on the command line, like this:

ReportBuilder.exe /s=http://localhost/reportserver "/My Favorite Report"

ReportBuilder.exe /s=http://localhost/reportserver "/model=/Models/Adventure Works"

Again, this feature is not supported in this release. If you run into problems and call MS product support, they will tell you to go jump in a lake. :)

Using that little checkbox in the Report Builder filter dialog

bobmeyers — Mon, 15 Jan 2007 21:19:00 GMT

The Filter dialog in Report Builder has a little checkbox near the bottom that many users have asked about. The checkbox label says, "When adding a new condition, apply to all data in my report."

The effect of selecting this checkbox is that when subsequent fields are added to your filter, and those fields have a to-many relationship from the primary entity, an attempt will be made to adjust the query so those conditions filter not only the rows in the report, but the totals as well. This is the default behavior, and mimics the familiar "slice-and-dice" approach to filtering.

If the checkbox is not selected, no attempt will be made to ensure the conditions you add affect your totals. They will only affect the set of rows displayed in your report. (Technically, they will only affect the set of rows from the primary entity that contribute to the rows in your report. If you are not displaying individual rows from the primary entity, e.g. you are grouping on a field instead, a new filter condition may still affect your totals even though the checkbox is not selected.)

For example, if I add Customer Name and Total Sales to a new report, then open the Filter dialog and add a filter condition specifying Customer.Orders.Order Year = 2006, two things could happen:

If the checkbox is selected, the primary entity will change from Customer to Order, and the filter will now be an Order filter. This will affect the set of rows displayed (only Customers with Orders in 2006 will be displayed), and the Total Sales field (only sales from Orders in 2006 will be included).

If the checkbox is not selected, the primary entity will remain Customer, and an aggregate filter group ("Any Orders with...") will be created instead. This will affect the set of rows displayed (only Customers with any Orders in 2006 will be displayed), but it will not affect the Total Sales field (it will continue to show their all-time sales). This allows you to isolate the row filter from the filter used for totals.

I want to reference a parameter (twice!) in a formula filter condition

bobmeyers — Thu, 21 Dec 2006 03:32:00 GMT

In this release of Report Builder there is no direct support for referencing parameters in the Formula dialog. They will show up if you edit a prompted filter condition as a formula, but there is no way to directly insert a parameter reference.

However, with a little trickery and relying on some behavior that is arguably a bug J, you can get one (or even two!) parameter references into the formula:

1. Add a field to your filter

2. Click the field name and choose Prompt

2.5. Do this if you want two references: Click the operator (usually “equals”) and choose From…To

3. Click the field name and choose Edit as Formula

This will give you a formula with one or two references to the parameter. You can edit the rest of the formula to get what you want -- just don't delete the ones you have, because you won't be able to reinsert them. Hopefully two is enough, because I can’t think of any way to get three.

Enforcing timeouts on Report Builder queries

bobmeyers — Tue, 31 Oct 2006 22:12:00 GMT

I've attached a sample C# project illustrating how to create a custom data processing extension (more info) that enforces a maximum timeout on any SQL queries submitted to it, including those generated from Report Builder.

To try it out:

Open and build the attached C# project in VS.
Copy output assembly to the ...\ReportServer\bin folder.
Add the config entries indicated in the NewConfigEntries.txt file (included in the project).
Use Report Manager to edit the properties for the data source your report model is bound to, and change the connection type to "Microsoft SQL Server (timeout)".
Run a report against the report model that has a long-running query.
Notice that the database query and report processing are cancelled after the timeout specified in the config file. This occurs regardless of the setting in the report (which RB always sets to 0=infinite).

Because mapping the SQL semantic query engine to something other than the built-in SQL data extension is technically not supported, the proverbial disclaimer applies: If you try this at home and it works, great; if something bad happens and you ask MS product support to fix it for you, they will tell you to go jump in a lake.

That said, hopefully some will find this helpful.

UPDATE: The new config entries identified in the attached file are based on a recent internal SP2 build. If you aren't running SP2 (not likely, since it hasn't been released yet), ignore the SemanticQuery entry and just copy your existing one, changing the name attribute to match the name of the new custom data extension.

UPDATE 5/8/2009: Updated attachment to fix issue in SQL 2005 SP3 and SQL 2008 (need to implement IDbConnectionWrapper). I updated the policy config entry to use the default install location for SQL 2008, and upgraded the project file to VS 2008. Thanks to hawdong for pointing out the issue.

How to enable Report Builder for non-domain users

bobmeyers — Thu, 28 Sep 2006 18:26:00 GMT

Report Builder uses a client technology called ClickOnce to download and launch the application files. This component runs outside of Internet Explorer, so it cannot leverage any credentials that may have been collected by IE to access the report server. It can only access and download the Report Builder application files if the user's default credentials are sufficient. There are three ways to satisfy this constraint:

1. Client and server have a trust relationship (e.g. same domain), the user is logged into the client using a domain account with permission to access RB files on the report server, and Windows authentication is enabled on the ReportBuilder folder in IIS.

2. User has stored credentials on the client for the report server, using either the "Remember my password" checkbox in Internet Explorer or the Stored User Names and Passwords control panel, those credentials are Windows credentials, and Basic authentication is enabled on the ReportBuilder folder in IIS. This option is recommended only if you are using SSL, and only if the requirement that users store their credentials is acceptable. Note that if they do not, the application download will simply fail -- they will not be prompted to supply any credentials.

3. Anonymous access is enabled on the ReportBuilder folder in IIS. This may make your server vulnerable to denial-of-service attacks if it is not operating in a trusted environment.

Note that the authentication settings on the ReportBuilder folder in IIS are usually inherited from the report server virtual root.

Adding parameters (prompts) to a Report Builder report

bobmeyers — Thu, 16 Mar 2006 06:15:00 GMT

You easily can add basic parameters to a Report Builder report using the Filter dialog. For example, to let the user choose which year to view sales data for, add an Order Year filter condition to your report filter, then, instead of specifying a value, click the "Order Year" label on the left side of the condition and choose "Prompt" from the menu. This will create a corresponding report parameter that will supply the value when the report is run. If you also specify a value in the filter dialog, this value will be used as the default parameter value.

Report Builder launch parameters

bobmeyers — Wed, 25 Jan 2006 00:18:00 GMT

To launch Report Builder, use one of the following URLs (also documented on MSDN):

http://<servername>/reportserver/reportbuilder/reportbuilder.application (Full Trust)
http://<servername>/reportserver/reportbuilder/reportbuilderlocalintranet.application (LocalIntranet permissions only)

In addition to this, several launch parameters are supported:

To automatically open a specific report:
Append "?<reportpath>" to the URL (e.g. http://.../reportbuilder.application?/My+Reports/Quarterly+Sales+By+Region)

To automatically load a specific report model:
Append "?model=<modelpath>" to the URL (e.g. http://.../reportbuilder.application?model=/Models/Adventure+Works)

To automatically load a perspective of a specific report model:
Append "?model=<modelpath>&perspective=<perspectiveID>" to the URL. Note this is the ID of the perspective, not the Name.