Bob's SQL Reporting Services Blog : Tricks

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!

Localizing a report model

bobmeyers — Tue, 28 Apr 2009 02:15:00 GMT

Reports and report models can be localized at many levels. Following are some ideas around the current support in SQL Server 2008 for each type of localization.

- Localized metadata at report design time

o Example: Spanish report author sees “Cliente” instead of “Customer” in model explorer

o Report models do not support multiple languages for metadata names in a single model file

o It should not be difficult to build a custom solution to generate localized versions of the model file

§ Original .smdl file + XML file with localized entity/attribute/role names => localized .smdl file

§ Could use either XSLT or minimal code

o If implemented, reports would run against any localized version of the model because IDs are unchanged

o Metadata displayed in the report (such as column labels) would be in the language of the person who designed the report. Since they are merely text values copied in from the model explorer, they would not change at report run time.

- Localized metadata at report run time

o Example: Spanish report consumer sees “Cliente” instead of “Customer” in report column label

o SQL RS reports do not directly support localization of text labels in a report

o Some customers have implemented this using a custom “resource” assembly deployed on the server, and all labels in the report are replaced at report design time with expressions that retrieve the appropriate resource string from the custom assembly (sample)

o This is obviously cumbersome to set up at report design time, but it does work

- Localized data formatting at report run time

o Example: Spanish report consumer sees numeric and date values in the report data formatted as “1.234,56” and “27/04/2009” instead of "1,234.56" and "04/27/2009".

o This is supported by the default number formats available on the ribbon in Report Builder 2.0. In the dialog box, select the “Use regional formatting” checkbox.

- Localized data values at report run time

o Example: Spanish report consumer sees product category “Bicicletas” instead of “Bicycles” in report data

o This is typically done by storing localized values in the database as separate columns or as lookup tables based on user culture.

o Offhand I can’t think of a slick way to do this with report models. If you have some ideas, let me know.

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

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.

Creating a report model that can be used against multiple databases

bobmeyers — Thu, 28 Sep 2006 21:20:00 GMT

Sometimes it is useful to create a report model that can be used against multiple databases that have the same structure, but reside on different servers and/or have different schema qualifiers.

Uploading a second copy of a report model and pointing it at a different database is certainly easy enough, but you can run into issues if the second database has different schema qualifiers. The problem is that, by default, the Data Source View wizard creates a DSV that includes schema qualifiers in the bindings. If those qualifiers are not necessary (i.e. the bindings can be fully resolved if a default database is specified in your data source connection string), you can make your report model work for the second database by opening the .dsv file in a text editor and use Find/Replace to simply remove all the schema qualifiers.

Test it out against the old and new databases, and you should be good to go.

How to get the SQL for a Report Builder report

bobmeyers — Wed, 05 Jul 2006 21:10:00 GMT

There are two ways to get the generated SQL for a Report Builder report (or for a model-based query in any RS report): 1) use SQL Profiler to capture the incoming SQL commands, or 2) enable query logging in the report server.

To enable query logging on the report server (option #2), make the following change to the web.cofig file in your ReportServer install directory:

Before:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
...
<RStrace>
...
<add name="Components" value="all,RunningJobs:3,SemanticQueryEngine:2,SemanticModelGenerator:2" />
</RStrace>

After:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
...
<RStrace>
...
<add name="Components" value="all,RunningJobs:3,SemanticQueryEngine:4,SemanticModelGenerator:2" />
</RStrace>

You can then run a report and you will find the corresponding SQL statement in the log file at:

...\Reporting Services\LogFiles\ReportServer_<datetime>.log

Using RDL expressions in Report Builder

bobmeyers — Sun, 26 Mar 2006 05:57:00 GMT

While not a documented feature, you actually can enter an arbitrary RDL expression into a textbox in a Report Builder report. For example, you could add a textbox that shows the date the report was run by setting the value of the textbox to the following:

=String.Format("Date: {0:MM/dd/yyyy}", DateTime.Today)

Another potential use of this undocumented feature is to display the values selected by the user for each report parameter. This is a helpful workaround for the fact that the auto-generated filter description does not insert the run-time values for each parameter. Here's an example of an RDL expression that would provide this info:

=String.Format("Sales Year: {0}", Parameters!OrderYear.Value)

Note that you will have to guess the name of the report parameter generated by Report Builder. Typically it will be the name of the field used in the prompted filter condition, with any spaces removed.

You cannot enter an RDL expression directly into a detail or subtotal cell in a table or matrix.

How to create a 'company' security filter for a hosted application

bobmeyers — Sat, 25 Mar 2006 04:02:00 GMT

Several customers have asked how to restrict data visibility in a report model for a hosted application, where every table has a "CompanyID" column, and every user that accesses the system is associated (via some other table) with exactly one company. The straightforward solution is to create a security filter on each corresponding entity; the filter should check whether any rows exist in the user table entity where Users.CompanyID=This.CompanyID and UserTable.UserID=GETUSERID(). This will work, but the SQL that is generated for this filter may not be optimal.

~~An alternative is to modify the DSV for the report model such that each table containing a CompanyID is really a named query of the form:~~

~~SELECT t.*, u.UserID FROM MyTable t, UserTable u WHERE t.CompanyID = u.CompanyID~~

Note that this derived table contains n rows for each row in MyTable, where n is the number of users associated with that row's company. To effectively fool the model, you will need to lie in the DSV and claim that the primary key of your derived table is composed of only the key columns for MyTable.

You must then create a security filter on the corresponding model entity for MyTable, which simply states UserID = GETUSERID(). If you create any other security filters for that entity, they MUST contain the same filter condition, in addition to any other conditions. No user should be given access to all the rows of that entity.

~~This approach, while a bit of a hack, should result in much better SQL at runtime.~~

~~Credits to my illustrious colleague~~ ~~Chris Hays~~ ~~for coming up with this.~~

UPDATE: The alternative proposed above does not work correctly in all cases because of an optimization we do in the SQL translation layer. Best practice is to stick with the "straightforward solution" described at the beginning of the post.

Collapsing a many-to-many relationship in a report model

bobmeyers — Fri, 24 Mar 2006 21:51:00 GMT

Often a many-to-many relationship exists between two entities where the intermediate entity has nothing on it except the connecting roles. For example, it might be that an Employee can be assigned to many Regions, and each Region can have many Employees assigned to it, but there is nothing interesting about an Employee Region (the intermediate entity).

In such cases, you can effectively hide the intermediate entity from your users by doing something like the following, where the three entities involved are A -< B >- C:

1. Rename the role from A to B as "Cs"
2. Rename the role from C to B as "As"
3. Set ExpandInline=True on the role from B to C
4. Set ExpandInline=True on the role from B to A
5. Add the role from B to A to the HiddenFields collection of the role from A to B
6. Add the role from B to C to the HiddenFields collection of the role from C to B
7. Set Hidden=True on entity B
8. Set Hidden=True the # Bs attribute (or just delete it)

Once you've done this, entity B is effectively hidden from the user. The only exception will be in the Formula dialog, where if the user displays the expanded formula for a field related via this path, the individual roles from A to B and B to C will be displayed. Other than that, as far as a Report Builder user can tell entity B does not exist.

How to create an inline bar chart

bobmeyers — Sat, 15 Oct 2005 08:44:00 GMT

Here's a neat trick a co-worker and I discovered this afternoon for creating an inline bar chart (an inline data visualization in a table or other data region).

1. Add an embedded image to your report that will serve as the "bar" (a simple horizontal gradient usually looks nice)

2. Add a column to your table, and place an Image report item in the detail row cell.

3. Select the embedded image from step 1 as the source for the Image report item.

4. Set the padding on the Image report item to adjust the size and position of the bar within the cell

5. [Here's the kicker] Create an expression for the right (or left) padding that divides a field value by some maximum value, clamps it to a given range if necessary using Math.Min/Max, and then multiplies by the total size of the bar.

Example: image1.Padding.Right=((1.0-(Math.Min(Math.Max(Fields!TotalSales.Value,0),100000)/100000))*72) & "pt"