Reports Never Stop Loading With VS 2010
2015-06-03 16:53
417 查看
’ve received a number of questions from people who have run into problems after upgrading their web application from VS 2008 to VS 2010. Once upgraded, the report viewer shows the loading indicator indefinitely - the report never loads. So what happened?
In an
earlier post, I talked about the changes we made to
AsyncRendering. Asynchronous rendering no longer renders the report content in an iframe. Instead, it uses ASP.Net AJAX to perform an asynchronous postback to get the report data. In most of the cases I’ve seen, this change is at the heart of the problem.
With the iframe model, the report data was retrieved through the report viewer’s HTTP handler. This request is distinct from a request to the ASPX page itself that contains the report viewer control. The communication between the browser and the web front
end would be something like this:
Browser makes a GET request to the ASPX page to get the page content and a loading indicator for the report
Browser makes a GET request to the HTTP handler to get the HTML for the report (this is the iframe content)
Browser makes GET requests to the HTTP handler to get all the images in the report
But with VS 2010, there are no more frames. Instead, we use ASP.Net postbacks to render the report. The new communication sequence is:
Browser makes a GET request to the ASPX page to get the page content and a loading indicator for the report.
Browser makes a POST request to the ASPX page to get the HTML for the report (this content is in an UpdatePanel).
Browser makes GET requests to the HTTP handler to get all the images in the report
In step 2, previously only the ReportViewer code would run to get the report content. But now the request to get the report content runs the ASP.Net page, including any code you have placed in the page.
Why does this matter? In the cases I’ve seen in the
forums and on Connect, code was added to the
load event of the page that altered the state of the report viewer. The most common example I’ve seen is user code calling
SetParameters in the load event, though there are several methods and properties that will trigger this. Changing the parameter values tells the ReportViewer that it needs
to restart report processing. Effectively, it tells the viewer to return to step 1 – put the loading indicator in the browser and restart report processing. If you do this during every postback, the viewer never successfully completes step 2. It just goes
into an infinite loop.
Calling methods like SetParameters isn’t cheap. Each call triggers a round trip to the report server. So it’s a call you want to minimize anyway. By only calling SetParameters during the initial GET request or only when parameter values have actually
changed, you can improve the performance of your application and break the loop. A simple check of
IsPostBack before calling SetParameters is usually sufficient.
In an
earlier post, I talked about the changes we made to
AsyncRendering. Asynchronous rendering no longer renders the report content in an iframe. Instead, it uses ASP.Net AJAX to perform an asynchronous postback to get the report data. In most of the cases I’ve seen, this change is at the heart of the problem.
With the iframe model, the report data was retrieved through the report viewer’s HTTP handler. This request is distinct from a request to the ASPX page itself that contains the report viewer control. The communication between the browser and the web front
end would be something like this:
Browser makes a GET request to the ASPX page to get the page content and a loading indicator for the report
Browser makes a GET request to the HTTP handler to get the HTML for the report (this is the iframe content)
Browser makes GET requests to the HTTP handler to get all the images in the report
But with VS 2010, there are no more frames. Instead, we use ASP.Net postbacks to render the report. The new communication sequence is:
Browser makes a GET request to the ASPX page to get the page content and a loading indicator for the report.
Browser makes a POST request to the ASPX page to get the HTML for the report (this content is in an UpdatePanel).
Browser makes GET requests to the HTTP handler to get all the images in the report
In step 2, previously only the ReportViewer code would run to get the report content. But now the request to get the report content runs the ASP.Net page, including any code you have placed in the page.
Why does this matter? In the cases I’ve seen in the
forums and on Connect, code was added to the
load event of the page that altered the state of the report viewer. The most common example I’ve seen is user code calling
SetParameters in the load event, though there are several methods and properties that will trigger this. Changing the parameter values tells the ReportViewer that it needs
to restart report processing. Effectively, it tells the viewer to return to step 1 – put the loading indicator in the browser and restart report processing. If you do this during every postback, the viewer never successfully completes step 2. It just goes
into an infinite loop.
Calling methods like SetParameters isn’t cheap. Each call triggers a round trip to the report server. So it’s a call you want to minimize anyway. By only calling SetParameters during the initial GET request or only when parameter values have actually
changed, you can improve the performance of your application and break the loop. A simple check of
IsPostBack before calling SetParameters is usually sufficient.
相关文章推荐
- shell脚本抓取问题进程(守护进程)
- Linux命令 bc - 浮点计算器、进制转换
- os.popen与os.system区别
- CentOS开放80、22、8080端口操作
- Linux下踢用户下线
- centos7下配置dns服务器
- Hadoop中-put和-copyFromLocal的区别
- 在Ubuntu等64为Linux下安装google android
- UVa 10934 Dropping water balloons
- Linux netstat命令详解
- heartbeat(v2)实现LAMP提供wordpress博客站点高可用模型实践
- 在Mac系统上安装Tomcat
- apache 配置虚拟主机。
- previous operation has not finished
- 使用Nginx提供web服务
- zabbix监控percona容器
- centos下安装iftop
- centos下安装iftop
- docker构建percona容器
- linux安装mysql 源码安装mysql