asked
Report Times Out in .net Reporting Application
We have a custom .net Report Application that is attempting to load a slightly data intensive SSRS report. Strangely, the report runs fine and returns data, albeit a little slow, when it is ran through the Report Manager and Mozilla Firefox. The problem is when a user attempts to load it through the Report Application in IE9, when all parameters are selected to maximize the data returned (20k rows), the report gets stuck on the Loading animation. The browser ultimately freezes and needs to be force-closed. There is no time-out time specified in the dataset of the report object itself, nor are any time-out settings specified in Report Manager. The Report Server execution logs show a TimeDateRetrieval and TimeProcessing time that indicates the report is loading successfully. Our belief is that there is a setting on the Report App that needs to be tweaked. We have already configured the httpRunTime parameter in the web.config file to: We have also attempted configuring the
ViewReport.aspx file as follows Any suggestions?
Twenty thousand rows?!?! Is someone really going to use that report and make decisions on it? I think you have proved yourself that the issue is the amount of data being handled and the way that FF and IE do it differently. Reducing the row count will probably find you a place where IE works to but i would be looking to split this report into a summary report and then link to a detail one so that the report user can drill in to get the detail they need. With this split I'd expect IE to handle the reports with no problem. If the report is going to be exported straight to Excel then why not point PowerPivot at the view/procedure that is supporting your report and let them analyse it in Excel from the get-go.
Johnathan, thanks for your recommendations. I will run the possibility of a redesign of the report by my clients, using a Summary layout and possibly a drill-through detail report showing narrower segments of the data. The 20k row result-set is not how the report is meant to be run, but instead it is the "most strenuous" case scenario, which we were looking for and discovered after we put the report into production (which evidently had abundantly more data than other environments). Anyways, even if a redesign of the report provides a temporary work-around for this issue, we will still want the wider issue addressed as to why our Report Application chooses to stop loading large reports, while Report Manager and Firefox pose no problems...
We have fixed the issue by configuring the ASyncPostBackTimeOut property in the Report Viewer module to 0. Also, the pagination of the report was causing performance problems, since 20k rows were being loaded to 1 page. Separating large reports into multiple pages would also alleviate this issue.
14 People are following this question.
