Question

I’m using SSRS with SOAP data sources on SQL Server 2012. When a service times out the report user sees the following text on his/her browser…

• An error has occurred during report processing. (rsProcessingAborted)
  
  -The execution failed for the shared data set ‘XXXLookup’. (rsDataSetExecutionError)
  • Query execution failed for dataset ‘XXXLookup’. (rsErrorExecutingCommand)
    • Failed to execute web request for the specified URL. (rsXmlDataProviderError)
      ® The operation has timed out

Is there a way to configure a custom error handler in SQL Server 2012 Reporting Services to provide a user friendly message? (I have searched and found similar questions asked, and the answer is typically no, rs errors can’t be trapped by SSRS in versions earlier than 2012.)

Answer 1

Even though SSRS 2012 includes a section in the configuration files to ‘hook into’ SSRS events, per MSFT, you should not modify this section (from MSDN documentation):

“Event Processing
Specifies default event handlers. Do not modify this section.
This section is not extensible.”

So…where does that leave you? You could, of course modify the section of the web.config for SSRS, as described here. Of course that would only allow you to replace the default (unfriendly) error page with a slightly more friendly one, but it isn’t clear how you’d dynamically populate the REASON for the failure on this new, custom error page. Other customers are having the same issue, but no one at MSFT seems to be answering.

So, what would I do here? It would depend on the quantity of reports where you are having this issue. If only a small percentage of all possible reports, then I might put logic in the report itself via a custom extension, that populates a text box on the report if it doesn’t return the data in the desired time period.

Also a greater consideration is WHY are these reports rendering so slowly? I would ask the obvious questions of the users, such as ‘is there a large amount of data being returned – do you need / use that much data in each report?’, and ‘if a large amount of data is being returned, could it be shown pre-aggregated (by the source database)?’ Also, I would consider optimizing the queries at the data source, via indexing, more optimal query syntax, etc…

Another consideration is WHEN are the reports timing out? Is there a particular time of day? Is there congestion on the network at that time? Along these same lines, could the users accept a bit of latency, so that the reports could be rendered via scheduled snapshots, which might also speed their retrieval.