清理临时 SSRS 报告
我们的应用程序使用 SQL Server Reporting Services，并允许用户向报告添加自定义过滤器。为此，我们修改 RDL，然后将修改后的 RDL 上传到服务器以创建新报告。问题是，报表运行一次后就不再需要了；这实际上只是一份临时报告。显然，这最终会导致大量临时报告的出现。我们需要一种方法来清理这些。
我们已经考虑过外部方法，例如创建服务或作业来定期删除报告，如果我们不能想出更好的方法，这可能就是我们最终要做的。我们想知道的是，SSRS 本身是否提供了更好的方法来做到这一点？我们考虑尝试以某种方式使用将被设置为过期的缓存实例，但这似乎只适用于报告的已执行实例，而不适用于报告本身。据我所知，没有办法将报告设置为过期。还有其他方法让 SSRS 帮我们清理吗？
立即删除报告不是一个选择，因为我们的执行是异步的。
Our application uses SQL Server Reporting Services and allows users to add custom filters to reports. We do this by modifying the RDL and then uploading the modified RDL to the server to create a new report. The problem is that after the report has run once, it's no longer needed; it's really just a temporary report. Obviously, this would eventually result in a lot of temporary reports laying around. We need a way to clean these up.
We've already thought about external methods like creating a service or job to periodically delete the reports, and that's probably what we'll end up doing if we can't come up with something better. What we're wondering is, does SSRS itself provide a better way to do this? We thought about trying to somehow use a cached instance which would be set to expire, but that seems to only works on an executed instance of a report not the report itself. As far as I can tell there's no way to set a report to expire. Is there some other way to get SSRS to clean up for us?
Immediately deleting the report isn't an option because our execution is asynchronous.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
内置的，什么都没有。但自己写一些东西很容易。
尝试建立一个流程来查询报告目录中超过半小时（左右）的报告。您甚至可以加入 ReportServerTempDB 以查看它们是否仍然有活动会话（在这种情况下，您可以忽略它们一段时间）。
一旦找到它们，就可以使用 Web 服务界面轻松获取它们并将其从目录中删除。
但是......我实际上会寻找一种使用代码提供自定义过滤器的更好方法。当然，您可以提供过滤器作为参数，并使用报告中的 VB 代码将用户提供的内容转换为可以对每一行进行评估的内容。
抢
Built-in, there's nothing. But writing something yourself is easy enough.
Try having a process which queries your catalog of reports for ones that are older than half an hour (or so). You could even join to ReportServerTempDB to see if they still have an active session (in which case, you ignore them a bit longer).
Once you've found them, it's easy to grab that using the Web Service interface and delete them from the catalog.
But... I'd actually look at a better way of providing the custom filter, using code. Surely you could provide the filter as a parameter, and use the VB code within the report to convert what the user provides into something which could be evaluated for each row.
Rob