Bob's SQL Reporting Services Blog : Admin

Considerations for a large report model

bobmeyers — Mon, 27 Apr 2009 23:58:00 GMT

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

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

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.

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

Subscriptions to Report Builder reports

bobmeyers — Thu, 30 Mar 2006 20:31:00 GMT

Many people are interested in creating subscriptions to Report Builder reports. In SQL Server 2005 this is only possible if the reports can be run unattended by the server. If the report has any user-dependent behavior, then it can only be run live by a user. Unfortunately, enabling model item security on a report model causes all reports against that model to potentially have user-dependent behavior. Therefore, as of this writing you cannot create subscriptions against a model-based report when the model has model item security enabled. We expect to fix this in a future release (how soon has not been decided yet).

Article: Implementing Data Security in a Report Model

bobmeyers — Sat, 18 Mar 2006 21:03:00 GMT

I just posted the first article on my blog. Here's the abstract:

The report models introduced in SQL Server 2005 feature a number of ways to customize the data visible to different users and groups: perspectives, model item security, security filters, and opaque expressions. This article describes when and how to use each of these features.

Comments and feedback welcome!