Troubleshooting Techniques for Report Issues
New: 17 November 2008
Your first step in troubleshooting a report is to identify which components are involved. For example, if you view a report on the report server, you are viewing a report by using the HTML renderer in Report Manager. If you view the report in local preview, you are viewing a report in the report viewer control in Business Intelligence Development Studio. If you view a report that has been exported to Excel, you are using Excel on the local client computer to open the exported file. To understand and help solve issues, you must first identify the components that are involved in the issue. Collect as much information about the component or process possible. Use the information in this topic to learn about ways to troubleshoot report issues.
The following links provide more information on specific topics:
- Tips on how to diagnose time-out errors and out of memory errors. See How to diagnose issues when running reports in the report server on blogs.msdn.com.
- How to implement Reporting Services on different architectures to solve performance and scalability issues. See Planning for Scalability and Performance with Reporting Services on msdn.microsoft.com.
- How to improve report design to help improve report performance. See Troubleshooting Report Performance.
- Understanding report components and Reporting Services architecture. See Reporting Services Component Overview.
Technique: Monitoring Report Servers
You can use system and database tools to monitor report server activity. You can also view report server trace log files, or query the report server execution log for detailed information about specific reports. If you are using Performance Monitor, you can add performance counters for the Report Server Web service and Windows service to identify bottlenecks in on-demand or scheduled processing.
For more information, see Monitoring Report Server Performance.
Technique: Viewing the Report Server Logs
Reporting Services records many internal and external events to log files that record data about specific reports, debugging information, HTTP requests and responses, and report server events. You can also create performance logs and select performance counters that specify which data to collect. The default directory for log files for a default instance installation is <drive>\Program Files\Microsoft SQL Server\MSSQL.N\Reporting Services\LogFiles. For more information, see Reporting Services Log Files.
To determine specifically whether report waits are caused by data retrieval, report processing, or report rendering, use the Execution Log. For more information, see Report Server Execution Log.
Technique: Viewing the Call Stack for Report Processing Error Messages on the Report Server
When you view a published report in Report Manager, you might see an error message that represents a general processing or rendering error. To see more information, you can view the call stack.
To view the call stack, log on to the report server by using the local administrator credentials, right-click the Report Manager page, and then click View Source. The call stack provides detailed context for the error message.
Technique: Enabling Remote Errors on the Report Server
In Report Manager, when you view a report with an error, you might see this error message: "For more information about this error, navigate to the report server on the local server machine, or enable remote errors".
To display more information about the error, you can configure a remote report server to provide context information for the error message. For more information, see How to: Enable Remote Errors (Reporting Services Configuration).
Technique: Using SQL Server Management Studio to Verify Queries and Credentials
SQL Server includes SQL Server Management Studio, a management tool for business intelligence components. Use Management Studio to connect to your data source, open a query window, and create and validate complex queries before you include them in your report.
To test whether you can access the data source under a different security context, run Management Studio by using the Microsoft Windows Run As command and enter the credentials that you want to test. While Management Studio is open, connections to data sources use the specified credentials.
For more information, see SQL Server Management Studio Transact SQL Query and Using Object Explorer.
Technique: Analyzing Problem Reports with Report Data Cached on the Client
When a report author creates a report in Business Intelligence Development Studio, the authoring client caches data as an .rdl.data file, which is used when you preview a report. Every time the query changes, the cache is updated. To debug report problems, it is sometimes useful to prevent the refresh for report data so that the data does not change when you are debugging.
To control whether BI Development Studio uses only cached data, you can set the ForceCache property in the application configuration file devenv.exe.config. By default, the configuration file is located in the following directory: <drive>:Program Files\Microsoft Visual Studio 8\Common7\IDE. To prevent queries from refreshing the data, set ForceCache to 1. The following code shows the cache configuration as an XML fragment:
...
<system.diagnostics>
<switches>
<add name=
"Microsoft.ReportDesigner.ReportPreviewStore.ForceCache" value="1"
/>
</switches>
</system.diagnostics>
...
As long as ForceCache is set to 1, only cached report data is used. Be sure to remove this section when you have finished debugging the report.
See Also
Concepts
Other Resources
Reporting Services Errors and Events
Troubleshooting Reporting Services