如何防止 SSRS 图形图像超时（未找到流错误）？
我遇到一个问题，在几分钟后尝试仅请求图像（而不是同时刷新 HTML）后，SQL Server Reporting Services 图形图像 URL 变得不可用。
实际错误是： “找不到流。提供给操作的流标识符 无法在报表服务器数据库中找到。 (rsStreamNotFound)"
假设图像超时，有没有办法延长这个超时值？
环境很挑剔且不理想，但目前无法更改。该报告是通过 ASP.NET 应用程序生成的（进行 Web 服务调用并填充 ASP.NET 文字控件）并在 Outlook 2000 中的“Outlook Today”页面中呈现。请参见下图：
http://paulw.us/blog/uploads/outlooktoday.GIF
Reporting Services 运行 2008 年，但数据来自 SQL Server 2005 数据库。
I have an issue whereby SQL Server Reporting Services graph image URLs become unavailable after attempting to just request the images after a few minutes (instead of also refreshing the HTML).
The actual error is:
"The stream cannot be found. The stream identifier that is provided to an operation
cannot be located in the report server database. (rsStreamNotFound)"
Assuming the images are timing out, is there any way to extend this timeout value?
The environment is finicky and not ideal, but cannot be changed at this time. The report is being generated through an ASP.NET application (which makes a web service call and populates an ASP.NET literal control) and rendered in the "Outlook Today" page in Outlook 2000. See diagram, below:
http://paulw.us/blog/uploads/outlooktoday.GIF
The Reporting Services is running 2008, but the data comes from a SQL Server 2005 database.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
根据我的发现，显然没有办法做到这一点。我实施的解决方法是打开缓存并运行数据驱动的订阅来生成报告。这样做有一些问题，即它似乎并不总是阻止用户重新加载报告。
更可靠的方法是启用历史记录和批处理，该批处理会更改默认参数并创建报告，像数据驱动订阅一样循环遍历所有内容，但维护对哪个报告与哪个日期和历史 ID 对应的外部引用。例如，您可以有一个数据库表来跟踪报告运行时间、报告 ID 和参数集，并对其进行查询以了解根据您的参数显示哪些内容。
There's apparently no way to do this, from what I've found. The workaround that I've implemented is to turn on caching and run a data-driven subscription to generate the report. There are some problems with this, namely that it doesn't always seem to prevent the user from having to reload the report.
A more robust way is to enable history and a batch process that changes default parameters and creates the report, cycling through everything like in a data-driven subscription, but maintaining external references to which report goes with which date and history ID. For instance, you could have a database table that tracks the report run time, report ID and parameter set, and query against it to know which to display based on your parameters.