生成大型 RS 报告时出现奇怪的 DataRowView 错误
我有一个基于 DotNetNuke 构建的 ASP.NET 应用程序，在我的大学中用于学生管理。
有时，当生成一些长时间运行的报告时，应用程序会抛出如下错误：
DataBinding：“System.Data.DataRowView”不包含属性 名为 XXXX
其中 XXX 可能不同。
我必须强调，所有这些属性（似乎找不到）都存在，并且它们是由存储过程生成的（在 Sql Management studio 中查询时）。 95% 的时间代码可以工作，但是在生成报告时，它会停止工作...
重新编译或应用程序重新启动后，一切似乎都正常工作（直到我再次生成一些报告）。
DotNetNuke 站点可能一直可以成功访问，而我的模块会抛出之前的异常。 所有引发错误的模块都是使用 SqlServerDataSource 构建的。 我已经指定了 e.Command.CommandTimeout = 60; 但是...没有运气。 我们的应用程序使用 ObjectDataSource、SqlDataSource 和代码隐藏数据绑定。 这些错误似乎仅出现在使用 SqlDataSource 的页面中，而不出现在使用 ObjectDataSource 或代码隐藏数据绑定的页面中。
为了解决机器上的这个“谜团”，我们创建了另一个实例，在其中移动用于密集和大型报告（如数据仓库）的表。 对于本例，我们还安装了 Reporting Services。
因此，使用 SQL 2005：
- 实例 1：主生产数据库 + Reporting Services 实例 1 对于简单报告
- 实例 2：用于报告活动的数据库 + 报告 对于大型报告的服务实例 2，
我们还使用 1222 标志检查了死锁，但是当错误开始发生时，两个实例的日志中都没有死锁（实际上没有错误或警告）。
此外，主应用程序和两个报告服务实例都有单独的应用程序池。
服务器规格：
- 操作系统：Windows 2003 R2、64 位
- SQL Server 2005 Standard、64 位
- 8 GB RAM
- Intel Xeon E 5345 2.33 Ghz（2 个四核）
I have an ASP.NET application, built over DotNetNuke, used in my university for student management.
Any now and then, when generating some long-running report, the application throws an error like this:
DataBinding: 'System.Data.DataRowView' does not contain a property
with the name XXXX
where XXX may be different.
I have to emphasize that all these properties (that appear not to be found) exist and they are generated OK by stored procedures (when querying in Sql Management studio). 95% of the time the code works but, when generating reports, it stops working...
After a recompilation or application restart everything seems to work normally (until I generate some reports again).
The DotNetNuke site may be accessed successfully all this time, while my modules throw previous exceptions. All the modules that throw errors are built using SqlServerDataSource. I've specified a e.Command.CommandTimeout = 60; but... no luck.
Our application uses ObjectDataSource, SqlDataSource and code-behind data binding. These errors seem to appear only in the pages the use SqlDataSource but not in those using ObjectDataSource or code-behind data binding.
For solving this "mystery" on the machine we created another instance where we moved the tables used for intensive and large reports (like a data warehouse). For this instance we've also installed the Reporting Services.
So, the SQL 2005 is used:
- instance 1: main production database + Reporting Services instance 1
for simple reports - instance 2: database used for reporting activities + Reporting
Services instance 2 for large reports
we have also checked for deadlocks using the 1222 flag but when the errors start occurring there are no deadlocks (no errors or warnings, in fact) in the logs for both instances.
Also, there are separate application pools for the main app, and for both reporting services instances.
Server specs:
- OS: Windows 2003 R2, 64 bit
- SQL Server 2005 Standard, 64 bit
- 8 GB RAM
- Intel Xeon E 5345 2.33 Ghz (2 quad-core)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
使用 SQL Profiler 监视 SQL Server 中的错误。 这将告诉您是否是 SQL Server 愚蠢或者是否是 Web 服务器端的问题。
Use SQL Profiler to monitor the errors from the SQL Server. This will tell you if it's the SQL Server being stupid or if it is a problem on the web server side.