Bob's SQL Reporting Services Blog https://docs.microsoft.com/archive/blogs/bobmeyers/feed.xml Notes, tips, rants, and ruminations on SQL Reporting Services, and Report Builder in particular. Wed, 17 Apr 2019 03:20:26 GMT en-US hourly 1 Create short lists using the LookupSet function https://docs.microsoft.com/archive/blogs/bobmeyers/create-short-lists-using-the-lookupset-function Mon, 18 Jun 2012 12:19:00 GMT https://blogs.msdn.microsoft.com/bobmeyers/2012/06/18/create-short-lists-using-the-lookupset-function/ Sometimes you have a short list of values that you really don't want to show on individual rows; you'd rather just concatenate them into a list, separated by commas, and put them all in a single row.

For example, suppose instead of listing the states in each U.S. Census region each on their own row, I'd like to see something more like this:

You can do this in a Reporting Services report in SQL 2008 R2 or later, using the built-in LookupSet and Join functions together, like this:

=Join(LookupSet(thisfield, otherField, returnField, datasetName), delimiter)

Note that the datasetName will be the same as the dataset to which the table is bound. So, for example, in the above case I did the following:

=Join(LookupSet(Fields!Region.Value, Fields!Region.Value, Fields!StateCode.Value, "StateRegions"), ", ")

If the values are not sorted the way you like them, or they include duplicates, you can use the following very similar functions by inserting them into your report's Code block:

=Code.JoinSorted(LookupSet(...), ...)

=Code.JoinDistinctSorted(LookupSet(...), ...)

The code for these functions is attached.

Hope this helps!

Join sorted text code.vb.txt

]]> TechEd session: Tips and tricks for building rich reports https://docs.microsoft.com/archive/blogs/bobmeyers/teched-session-tips-and-tricks-for-building-rich-reports Mon, 18 Jun 2012 11:56:00 GMT https://blogs.msdn.microsoft.com/bobmeyers/2012/06/18/teched-session-tips-and-tricks-for-building-rich-reports/ Here's a recording of my TechEd 2012 North America session last week in Orlando:

Tips and Tricks For Building Rich Reports

The entire session is based on Report Builder 3.0. All content is relevant to both SQL 2008 R2 and SQL 2012.

Topics covered:

  • Use a tablix to organize data how you want it
  • Use colors and graphics to emphasize data
  • Choose the right visual for what you're trying to communicate
  • Add clipboard data using an XML data source
  • Integrate related data using the Lookup function
  • Display short lists using the LookupSet function
  • Optimize output for Excel

Hope you enjoy!

]]> When and why the primary entity changes when using a report model https://docs.microsoft.com/archive/blogs/bobmeyers/when-and-why-the-primary-entity-changes-when-using-a-report-model Mon, 27 Feb 2012 10:34:00 GMT https://blogs.msdn.microsoft.com/bobmeyers/2012/02/27/when-and-why-the-primary-entity-changes-when-using-a-report-model/ Got a few questions lately on this subject, so I thought I’d post some additional info that may be helpful.

First, a few related links that may be partially helpful:

Now for the full response.

As stated in the MSDN article linked above, the primary entity represents the “context” or “root” of the report or query. Those familiar with OLAP may like to think of it as the central “fact table” with a host of related “dimensions”. It is the set of detail data to which all grouping and total values are related. It is also the context in which the report filter is defined. In short, all data shown in the report is related somehow to the primary entity.

So, how does one choose the primary entity? Well, you don’t – at least, not directly. When you add the first field to your report, its containing entity becomes the primary entity. All other entities are then rearranged into a tree to show how they are related to the field you selected.

As you add more fields to your report, or change the report filter, the primary entity may occasionally shift. This only occurs in the following cases.

1. You add a field indicating you want to display a lower level of detail.

For example, suppose you started your report by adding a couple of Customer fields – Customer Name and Phone. These both belong to the Customer entity, so Customer becomes the primary entity for the report.

Next, you click on the related entity Orders, and add Sum of Sales Amount. Because this is a total, it does not indicate you want to display a lower level of detail, so the primary entity is unchanged. Also, because your report is primarily “about” Customers at this point, data about Orders with no related Customer is not displayed.

Suppose you then add Order Month from the Orders entity. Order Month is not a total, and a Customer can have many Orders with many different Order Months, so adding this field indicates you want to display a lower level of detail. To accommodate this, the primary entity shifts from Customer down to Orders.

As a result, the report now displays data about Orders and their related Customers, instead of Customers and their related Orders. This may seem like a subtle distinction, but it has some important effects. One is that Customers with no Orders are no longer included, as they were when the report was only about Customers. Conversely, data about Orders with no Customer are now included, though they were not previously. Another effect is that the report filter is now evaluated in the context of Orders instead of Customers. The impact of this will become clearer after the next point.

2. You add a filter suggesting the overall report is about a lower-level set of detail data.

In the example for #1, suppose that instead of displaying total sales for each Order Month, you wanted to filter the report to display only the sales for a particular Month or a particular Store. Typically, this means two things: (1) you want the totals to include only the Orders from that Month or Store, and (2) you only want to see the set of Customers that actually have Orders from that Month or Store (as opposed to a list of all Customers).

When you want both of these restrictions applied (and by default it is assumed that you do), this suggests the report is no longer “about” Customers, but rather about the lower-level set of detail data that relates the Customers you’re showing and the filter you’re trying to apply. In this case, the lower-level data that relates Customers and the filter you’re trying to create is Orders. Hence, the primary entity shifts from Customer down to Orders.

Note: To filter the totals without filtering the set of Customers displayed, you can apply a filter directly to the Sum of Sales Amount field, instead of applying the filter to the entire report. Conversely, to filter the set of Customers without filtering the total sales displayed, you can temporarily uncheck the little checkbox in the report filter dialog. See the related blog post linked above for more information.

3. (Less common) You add a group field to a report that contains only grand totals.

Suppose you clicked on the Orders entity first, and added Sum of Sales Amount. At this point, the primary entity is Orders, but if you run the report, all you see is a grand total of Sales Amount across all Orders. The grand total has not be broken down, or “grouped by” anything yet.

If you then add Customer Name (which is not a total) to the report, this will cause the total you added previously to be broken down or grouped by the new field. At this specific transition point, i.e. when you go from having all totals to at least one group field, the primary entity may shift up, in this case from Orders to Customer. The reason for this shift is to ensure you get the same result you would have gotten if you had added the same fields in the reverse order (e.g. Customer Name, then Sales Amount).

Other than this one case (#3), the primary entity shifts only incrementally in one direction – down – and only as needed based on the fields and filters you’ve selected. In most cases, this behavior provides the most stable experience and most intuitive results for your report. However, when repeatedly adding and removing many fields to/from a report, you may occasionally get into a situation where the primary entity has shifted too far down a particular path, which may make it harder to get a specific result. In that case, removing and re-adding your group fields should move things back into the desired state.

]]> Add Excel-like "color scale" conditional formatting to your reports https://docs.microsoft.com/archive/blogs/bobmeyers/add-excel-like-color-scale-conditional-formatting-to-your-reports Fri, 31 Jul 2009 20:09:00 GMT https://blogs.msdn.microsoft.com/bobmeyers/2009/07/31/add-excel-like-color-scale-conditional-formatting-to-your-reports/ 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!

ColorScales.vb.txt

]]> Localizing a report model https://docs.microsoft.com/archive/blogs/bobmeyers/localizing-a-report-model Mon, 27 Apr 2009 19:15:00 GMT https://blogs.msdn.microsoft.com/bobmeyers/2009/04/27/localizing-a-report-model/ 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.

 

]]> Considerations for a large report model https://docs.microsoft.com/archive/blogs/bobmeyers/considerations-for-a-large-report-model Mon, 27 Apr 2009 16:58:00 GMT https://blogs.msdn.microsoft.com/bobmeyers/2009/04/27/considerations-for-a-large-report-model/ Customer report models that vary in size from a few to a few hundred entities. Little Northwind with its 10 or so entities comes in around 200K, but we've seen models a hundred times that size (over 20 MB). One of the key drivers of model size is the constraint that you cannot build a query across multiple models, so the tendency is to pull more and more data into the "main" model.

 

Given that, I thought I’d share a few tips that may help if you want to build, deploy, and use a large report model.

 

1.       Configure the report server allow upload of large files. By default ASP.NET limits the file upload size to 4 MB. You will need to modify this setting if your model exceeds the limit.

 

2.       Consider removing the diagrams from the DSV. Typically the diagrams in a DSV account for ~20% of the uploaded model size. This information is only used by Model Designer, however, so removing it will not affect either the report server or a client like Report Builder. The DSV editor will not allow you to remove the default “<All Tables>” diagram, and if you do remove it, the editor will recreate it with a default layout the next time you open the file, so you will need to remove this diagram from the XML manually before publishing.

 

3.       Define perspectives in the model. Perspectives allow users to self-select a convenient subset of the model at the time they design the report. This reduces download time (only the subset is retrieved by Report Builder) as well as clutter during the design experience. In extreme cases, you may want to require users to choose a perspective. Note that perspectives are not a security feature. Also note that it is possible, though not particularly easy, to change the perspective used in a query after the query has been created.

 

4.       Use model item security. This reduces the subset of the model available to specific users and groups, which in turn reduces the download time and visual clutter for those users. Note that as of SQL 2008 report subscriptions are not supported when using model item security.

 

If you are using a large report model and have additional tips or questions, please contact me. We'd love to get your feedback.

]]> SQL Server 2008 SP1 available now with important Report Builder 2.0 updates https://docs.microsoft.com/archive/blogs/bobmeyers/sql-server-2008-sp1-available-now-with-important-report-builder-2-0-updates Wed, 08 Apr 2009 01:28:00 GMT https://blogs.msdn.microsoft.com/bobmeyers/2009/04/08/sql-server-2008-sp1-available-now-with-important-report-builder-2-0-updates/ 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 https://docs.microsoft.com/archive/blogs/bobmeyers/help-rb-2-0-users-find-and-use-shared-data-sources Sat, 28 Mar 2009 00:26:00 GMT https://blogs.msdn.microsoft.com/bobmeyers/2009/03/28/help-rb-2-0-users-find-and-use-shared-data-sources/ 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. :)

DefaultFolders.zip

]]> What is that extra column of 'AB.gAAAA=' values when I run a report model query? https://docs.microsoft.com/archive/blogs/bobmeyers/what-is-that-extra-column-of-ab-gaaaa-values-when-i-run-a-report-model-query Fri, 06 Mar 2009 12:36:00 GMT https://blogs.msdn.microsoft.com/bobmeyers/2009/03/06/what-is-that-extra-column-of-ab-gaaaa-values-when-i-run-a-report-model-query/ 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.

]]> Call for feedback: What are you doing with report models? https://docs.microsoft.com/archive/blogs/bobmeyers/call-for-feedback-what-are-you-doing-with-report-models Fri, 06 Mar 2009 12:22:00 GMT https://blogs.msdn.microsoft.com/bobmeyers/2009/03/06/call-for-feedback-what-are-you-doing-with-report-models/ Are you using a report model in your organization? The Reporting Services product team wants to hear from you!

  1. What type of organization is using the model (dept/workgroup, small/mid business, enterprise)?
  2. How long have you been using your model?
  3. What is the backend database for your model?
  4. How much data is behind your report model?
  5. Who is responsible for developing/maintaining the model in your organization?
  6. How much effort went into model design before you started using it?
  7. How has your model changed over time?
  8. How easy has it been to change without breaking reports?
  9. How many people use the model to build reports?
  10. What kind of people use the model to build reports (report developers, information workers, etc.)?
  11. What kind of reports is the model most and least useful for?
  12. What are the top three improvements you’d like to see related to report models?

Send me your responses and I’ll forward them to the product team. We build these technologies for you, so your feedback is critical! Thanks in advance for your help!

]]>