客户端 SSRS 2008 中的子报表过滤性能不佳
我正在尝试将现有的 Access 报告转换为客户端 SSRS 2008 报告，但在过滤方面我遇到了糟糕的性能。
通过一些背景知识，我将简化报告的目的。这是该模型的简化视图：
Orgainzation
|
Person
|
Credential
组织有人员，人员有凭证。该报告列出了按组织分组的人员，其中与人员一起列出的两列是他们通过组织拥有的凭据的逗号分隔列表（当然，它们是标准化存储的，但我在过程中将它们连接起来）使用普通的 FOR XML PATH 技巧检索列表）。仅此一点，该报告就可以正常工作并且表现令人满意。问题在于，现有报告提供了列表中存在的每种凭证类型的摘要以及总数。
因为两个串联列表不同，所以我无法单独检索外部结果，只能按它们进行分组。相反，我必须进行第二次检索，以便按组织获取所有单独的凭证类型。这不是问题，而且 SQL 速度很快，但报告却是另一回事了。
对于那些在家记分的人来说，个人结果集大约有 10,000 行，分为 500 组。组织级别的摘要结果集可能是 500 个组中的 1500-2000 行（基本上，每个组织有 3-4 个不同的凭证类型）
主要报告放在 tablix 中，并且在我必须放置的组页脚中处理凭据的组织级别摘要的子报告。在子报表上，我添加了一个行筛选器，可以使用报表参数对组织进行筛选。组页脚中的子报表项采用分组组织并将其传递到子报表。这是功能，但其性能不可接受。渲染数据子集（仅 200 个外部行）的测试报告花费了近 30 分钟。尝试在整个结果集上运行大约一个小时后引发了 OutOfMemoryException，并且应用程序使用了约 900MB 的内存。
鉴于主报告没有子报告运行得很快，我假设这与子报告、过滤或两者都有关。
所以，这是我的问题：
有没有办法提高子报表中行筛选器的性能？
I'm attempting to translate an existing Access report into a client-side SSRS 2008 report, and I'm experiencing terrible performance when it comes to filtering.
By way of a little background, I'll simplify the purpose of the report. This is a simplified view of the model:
Orgainzation
|
Person
|
Credential
Organizations have people, and people have credentials. The report lists people, grouped by organization, and two of the columns listeded with a person are comma-delimited lists of the credentials they have through the organization (they're stored normalized, of course, but I'm concatenating them in the procedure that retrieves the list using the ordinary FOR XML PATH trickery). With just this, the report works fine and performs acceptably. The issue is that the existing report provides a summary of each credential type that's present in the list, along with the total quantity.
Because the two concatenated lists are different, I can't retrieve the outer results individually and just group by them. Instead, I have to do a second retrieval in order to grab all of the individual credential types by organization. This isn't an issue, and the SQL is fast, but the report is another story.
For those keeping score at home, the person result set is roughly 10,000 rows in, say, 500 groups. The organization-level summary result set is probably 1500-2000 rows in 500 groups (that's 3-4 distinct credential types per organization, basically)
The main report is laid out in a tablix, and in the group footer I've had to place a subreport that handles the organization-level summary for the credentials. On the subreport, I've added a row filter that filters on organization using a report parameter. The subreport item in the group footer takes the grouped organization and passes it to the subreport. This is functional, but its performance is not acceptable. Rendering a test report on a subset of the data (only 200 outer rows) took nearly 30 minutes. Attempting to run on the entire result set threw an OutOfMemoryException after about an hour, and the application was using ~900MB of memory.
Given that the main report without the subreport runs quickly, I'm assuming this has to do either with subreports, filtering, or both.
So, here's my question:
Is there a way to improve the performance of row filters within a subreport?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
鉴于缺乏对此问题的答复，我将假设无法采取任何措施来提高客户端报告中的过滤性能。
Given the lack of response to this question, I am going to assume that there is nothing that can be done to better the performance of filtering in client-side reports.