John Gallardo's Weblog : Microsoft

Hiding parameter area when viewing reports

jgalla — Tue, 24 Mar 2009 00:19:36 GMT

When rendering reports, oftentimes the application would like to minimize as much of the non-report area of the viewer control as possible. This is easily accomplished when rendering the report through the built-in report viewer control hosted in the ReportServer web site (http://servername/reportserver).

There are two parameters which control the rendering of the viewer control area:

rc:Parameters
rc:Toolbar

rc:Parameters can have 3 values:

On	Displays the parameter area as in the screenshot above.
Off	Completely hides the parameter area.
Collapsed	Renders the parameter area initially minimized, so a user can expand it if they need to view/change the parameters for a report.

Here is an example URL which demonstrates rendering a report with rc:Parameters=Collapsed:

https://servername/ReportServer?%2fSamples%2fSQL+2008+Samples%2fAdventureWorks2008+Sample+Reports%2fEmployee+Sales+Summary+2008&rs:Command=Render&rc:Parameters=Collapsed

The other way of hiding the parameter area is to render the report with rc:Toolbar=false. For many applications though, there are side-effects of this approach which I don’t think are desireable. These are:

It disables the automatic ping-mechanism to keep the user’s report session alive. This can lead to rsExecutionNotFound errors if the user leaves the page inactive for several minutes.
It also removes the navigation (next page, find, etc…) UI.
By default, it will cause every page of the report to be returned to the client. For long reports, this is typically not desireable.

So if you are in a situation where you want to minimize the amount of extraneous UI initially presented to the user, while still allowing flexibility in having the end user change the parameter values, consider using rc:Collapsed=true when rendering the report.

Load Testing Reporting Services

jgalla — Tue, 16 Jan 2007 04:52:21 GMT

This question came across one of our internal discussion aliases, and it wasn't the first time I had seen it... so I thought it might be interesting to other people as well.

Oftentimes, when people configure a load testing tool they set it up so that all of the connections come from the same logical user. However, in Reporting Services we have a feature which prevents an authenticated user from performing a denial-of-service attack against the server. We do this by limiting the number of operations that any given user (based on the user's name) can be performing at any given time. When you hit this limit, you will get an error message like this:

There are currently too many requests in progress for user: "ABC\XYZ". Please wait until the current requests have finished processing before issuing any more.

At this point, there are basically two ways of resolving this issue:

Change your test scripts/application to spread the requests across multiple logical users.
Alter the rsReportServer.config file to extend the number of requests a user can have active. The setting is the <Configuration> section and it is the "MaxActiveReqForOneUser" property. The whole entry is this: <Add Key="MaxActiveReqForOneUser" Value="999999" />.

Note that this setting can also be useful if your users are not talking directly to the server, but are instead going through an ASP.Net application which is always impersonating the same user when accessing SSRS.

Diagnosing rsInternalError

jgalla — Tue, 05 Dec 2006 20:52:02 GMT

You know the one. You try to render a report and you end up hitting the dreaded "An internal catalog exception has occurred" error message. Generally speaking, this is an indication that something very bad happened within the server which is not necessarily due to any particular action you performed, but rather due to some internal check which failed or an exception which we were unable to recover from was thrown. We purposefully do not display the entire error message to prevent information disclosure. Instead, we write some more detailed information into one of our log files.

Tracking down the log file which contains the error can be a little tricky if you have never done it before. I am going to assume that the error was generated as a result of interaction with the SSRS Web server, which handles all interactive (non-subscription) requests. This is what you see when you are using the Report Viewer control in server mode, Report Manager, or talking to the ReportServer virtual directory directly via either SOAP or URL Access.

The log files for the web server are stored in %Program Files%\Microsoft SQL Server\<Instance>\Reporting Services\Log Files. First thing you will want to do is head over there and look for the most recent file that look has a name like "ReportServer__<TimeStamp>". There will be a lot of files which almost look like this (such as ReportServerService__Timestamp) but we aren't interested in those just yet. So crack open the log file which corresponds in time to when the internal catalog exception was thrown, and do a search for the string "InternalCatalogException". Once you have found the exception, you will see a couple of things:

A call stack which shows where the exception occurred.
Any previous exception which was handled and wrapped in our InternalCatalogException.

Here is an example:

w3wp!library!5!12/01/2006-15:36:47:: e ERROR: Throwing Microsoft.ReportingServices.Diagnostics.Utilities.InternalCatalogException: An internal error occurred on the report server. See the error log for more details., ;
Info: Microsoft.ReportingServices.Diagnostics.Utilities.InternalCatalogException: An internal error occurred on the report server. See the error log for more details. ---> System.Data.SqlClient.SqlException: Could not allocate space for object 'dbo.ChunkData'.'IX_ChunkData' in database 'ReportServerTempDB' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)
at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe)
at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
at Microsoft.ReportingServices.Library.CancelableSqlCommand.ExecuteNonQuery()
at Microsoft.ReportingServices.Library.ChunkStorage.CopyImages(Guid fromSnapshotID, Boolean fromIsPermanent, Guid toSnapshotID, Boolean toIsPermanent)
at Microsoft.ReportingServices.Library.ReportSnapshot.CopyImageChunksTo(ReportSnapshotBase target)
at Microsoft.ReportingServices.Library.RSService.RenderAsLive(CatalogItemContext reportContext, ItemProperties properties, ParameterInfoCollection effectiveParameters, Guid reportId, ClientRequest session, String description, ReportSnapshot intermediateSnapshot, DataSourceInfoCollection thisReportDataSources, Boolean cachingRequested, Boolean isLinkedReport, Warning[]& warnings, ReportSnapshot& resultSnapshotData, DateTime& executionDateTime, RuntimeDataSourceInfoCollection& alldataSources, UserProfileState& usedUserProfile)
at Microsoft.ReportingServices.Library.RSService.RenderAsLiveOrSnapshot(CatalogItemContext reportContext, ClientRequest session, Warning[]& warnings, ParameterInfoCollection& effectiveParameters)
at Microsoft.ReportingServices.Library.RSService.RenderFirst(CatalogItemContext reportContext, ClientRequest session, Warning[]& warnings, ParameterInfoCollection& effectiveParameters, String[]& secondaryStreamNames)
--- End of inner exception stack trace ---

Sometimes, this will be enough information for you to diagnose the situation and resolve it on your own. For example, maybe the database where the RS catalog is being stored has run out of disk space. Other times, things won't be particularly clear. In those cases I recommend either contacting Microsoft Support, or posting your question on the SSRS Forum at MSDN.

Live Reports and rsReportNotReady Error

jgalla — Thu, 31 Aug 2006 03:36:03 GMT

rsReportNotReady is only supposed to be thrown when a report is configured to run from an execution snapshot, and the execution snapshot has not yet been created. It is a pretty rare occurrence and the whole error code is really meant to cover the small window between setting the report to run from an execution snapshot and actually calling the UpdateSnapshot() method().

Recently, we here on the SSRS team saw a couple of cases where people were experiencing this error when the report was configured to execute live. Technically, there is one valid scenario that this can happen, and that is when you request one of the streams for the report (via RenderStream() or passing StreamId on the URL to the /ReportServer endpoint) before you have actually rendered the primary stream of the report. These customers weren't doing this though, they were rendering the report via the viewer control. After a bit of troubleshooting, we eventually narrowed the problem down to the fact that Snapshot Isolation was enabled on the ReportServer and ReportServerTempDB databases. Snapshot Isolation changes the locking semantics of the ReadCommitted isolation level, which broke some of our synchronization mechanisms -- we basically use the database as a distributed lock coordinator since we support scale-out by adding Report Server instances which don't directly communicate with each other. Snapshot Isolation changes the locking semantics in such a way as that we cannot do this with the current implementation.

So what was the solution for these customers? Disable Snapshot Isolation on the SSRS databases.

Are you still seeing the problem and you don't have Snapshot Isolation enabled on your ReportServer or ReportServerTempDB database? If so please let me know.

Windows Live Writer

jgalla — Mon, 14 Aug 2006 00:58:13 GMT

The Windows Live folks just released Windows Live Writer. It's a tool which runs on your desktop and lets you publish blog entries to a bunch of different weblog formats. This is a test post on my MSDN blog.

So far I think it is pretty cool. It autodetected all of the settings on my MSDN blog, and hopefully this will publish without any problems. I have lost more than a couple of blog posts in the web-based editor, so hopefully this will save me some of that pain.

Go check it out!

Interviewed for SQLServerCentral.com

jgalla — Thu, 03 Aug 2006 20:12:00 GMT

Steve Jones recently interviewed me for a regular column he has on sqlservercentral.com. Check it out!

http://www.sqlservercentral.com/columnists/sjones/sqlserverspotlightonjohngallardo.asp

Should I modify Reporting Services stored procedures?

jgalla — Fri, 30 Jun 2006 20:00:00 GMT

The answer, is quite simply "No."

Someone shot a post from Google Groups through my inbox this morning where some people were having problems with session timeouts (they were seeing rsExecutionNotFound exceptions). Their "solution" was to edit the stored procedures that manage user session in our catalog database in attempt to prevent them from encountering this issue.

This is wrong for a couple of reasons:

If you think you are encountering a bug, please let us know about it. You are probably not the only person hitting it. We would like to fix the issue or provide a workaround to make all of our customers happy.
You don't know what you are doing. Unless you have access to the source code for the entire product you are not going to be able to infer all of the semantics associated with the stored procedure. Altering it will put your system in a completely untested state, making it very difficult for us to provide support for you.

Reporting Services and Windows Authentication

jgalla — Fri, 17 Mar 2006 02:34:00 GMT

Windows Authentication is good stuff, and rightly so many people are using it in their Reporting Services deployments. Lately, there has been quite a rash of questions that people have regarding the inability to connect to their data sources when using Windows Authentication. Usually the scenario is that they have RS on one box, their data is on another. When they are developing on the RS box, everything works fine, but when connecting from other machines they run into authentication issues.

This is not a situation which is unique to RS. The issue is usually the infamous "double hop" issue with IIS. In a nutshell, what happens is that the that credentials which are passed into IIS cannot passed to another machine for authentication. In RS, you have a couple of workarounds. You can choose to store the Windows credentials in our catalog where we will encrypt them and use them when establishing a connection to the data source. Or, you can configure your network to allow Kerberos delegation.

Using XML value() method to take advantage of a relational index

jgalla — Thu, 05 Jan 2006 22:32:00 GMT

The Performance Optimizations for XML Data Type in SQL Server 2005 whitepaper written by Shankar gives some pretty good advice for writing your XQuery statements so that they take advantage of an available XML Index. However, oftentimes you will have to deal with incoming XML data which is represented as a variable and hence is not indexed. In such a scenario, it is common to map some incoming values their corresponding representations within your database. For example, you may want to map a particular customer name in an XML instance to their corresponding customer id in your relational store for the purpose of updating some record. For mapping this value, you have basically two options, use exist() to perform the comparison in the XQuery context, or use value() to perform the comparison within the SQL context.

After reading the performance optimization paper you will probably be inclined to use exist() method, however you might be surprised at the performance benefit you will get by using value() method in some cases. Lets outline one of those cases now.

My scenario is pretty simple, I have a table with customer information, and another table which stores calls that this customer has made. Imagine I am a cell-phone provider or something. I will receive chunks of XML which indicate the customer that called (referenced by some billing code), the phone number the customer called, and the number of minutes the call lasted. Each packet of XML will contain multiple such records. I store the data relationally in the following schema:

create table [customers] (
[id] int primary key identity(1,1),
[billing_code] varchar(32) unique,
[name] varchar(32)
) ;

create table [calls] (
[call_id] int primary key identity(1,1),
[customer_id] int foreign key references [customers] (id),
[number] varchar(32),
[minutes] int
) ;

insert [customers] ([billing_code], [name]) values ('JOHN123', 'John')
insert [customers] ([billing_code], [name]) values ('DENN456', 'Denny')

Note that the unique index on the [billing_code] column in the [customers] table will implicitly create a nonclustered index on that column.

The goal now is to write a stored procedure which will accept the XML data, and perform the appropriate insertions into the relational data. My first attempt will use nodes() and exist() method to map the [billing_code] to the appropriate [customer_id] for insertion into the [calls] table. Also, let me show you an example instance which I will be parsing:

declare @callSummary xml
set @callSummary =
N'<CallSummary>
   <Call billingCode="JOHN123" callTime="5" number="555 123-4567" />
   <Call billingCode="DENN456" callTime="1" number="555 456-0000" />
   <Call billingCode="DENN456" callTime="10" number="555 456-0010" />
   <Call billingCode="DENN456" callTime="15" number="555 456-0001" />
</CallSummary>'

The resulting stored procedure which uses nodes() and exist() is the following:

create proc parseSummaryExists
@callSummary xml
as
begin
insert [calls] ([customer_id], [number], [minutes])
  select [cust].[id],
      [call].[ref].value('@number', 'varchar(32)'),
      [call].[ref].value('@callTime', 'int')
  from @callSummary.nodes('/CallSummary/Call') [call]([ref])
  join [customers] [cust]
   on 1 = [call].[ref].exist('@billingCode[.=sql:column("cust.billing_code")]')
end

By looking at the plan that is generated for this update, it can be seen that we aren't really taking advantage of our index on the [billing_code] column. Instead, we are simply scanning that index and sucking all of the values out, and joining that with each billingCode attribute from our xml instance. This is not a solution that will scale well as we get more customers! One problem that we have is since the comparison is being done in XQuery, we have to use XQuery comparison semantics. This comparison is not collation-sensitive, and since it is possible for the billingCode attribute to have more than 32 characters, we have to perform the comparison using an nvarchar(max). In other words, we simply don't have enough information in our index to perform this comparison in XQuery efficiently.

Rather then trying to perform the comparison in XQuery, why not perform the comparison using T-SQL and the value() method? Here is a similar stored proc which uses the value() method:

create proc parseSummaryValue
@callSummary xml
as
begin
insert [calls] ([customer_id], [number], [minutes])
  select [cust].[id],
      [call].[ref].value('@number', 'varchar(32)'),
      [call].[ref].value('@callTime', 'int')
  from @callSummary.nodes('/CallSummary/Call') [call]([ref])
  join [customers] [cust]
   on [cust].[billing_code] = [call].[ref].value('@billingCode', 'varchar(32)')
end

Now, looking at the plan here, we can see a nested loops join where for each <Call> element in the incoming xml, we perform an index seek on the [customers] table to find the appropriate customer id. This solution will scale in terms of the size of the incoming data, rather than the total number of customers.

There are a couple of key points here to recognize. The first is that the two queries are not the same. One truncates the XML text node to 32 characters for the purposes of being able to perform a quick index lookup. Depending on your scenario this may not be desireable, and you will want to perform the comparison using XQuery semantics. In this case, you should use exist() but be aware that you may not be able to take much advantage of your existing relational indexes. Another point is that value() is not just for "top level" projects of data from your XML instances, but can also be a useful tool for performing comparisons in the SQL context. Finally, The last point that I am trying to make is that there is no silver bullet for getting the most performance out of your XQuery statements. It is just as wrong to say "use exist()" as it is to say "use value()" for comparisons because they do different things. Instead, you should carefully analyze your scenario by looking at the plans that are generated and make your decisions based on that.

More Gadgets!

jgalla — Tue, 01 Nov 2005 17:50:00 GMT

http://microsoftgadgets.com/default.aspx

The "gadgets" folks have updated their blog to include some gadgets that you can add to start.com. I'm trying out the "Flickr" gadget as well as the "to-do" list gadget. Are you using start.com yet?