我们正在将报表服务器从 SSRS 2005 升级到 SSRS 2008 R2。
我对 SSRS 2008 的 CSV 导出呈现存在问题,其中列的总和出现在 2008 年的详细信息值的右侧,而不是像 2005 年那样的左侧,如下面的块所示。
117
和131
分别是 Column2 和 Column3 的总和。
SSRS 2005 CSV 输出
Column2_1,Column3_1,Column2,Column3
117,131,1,2
117,131,1,2
117,131,60,23
117,131,30,15
117,131,25,89
SSRS 2008 CSV 输出
Column2,Column3,Column2_1,Column3_1
1,2,117,131
1,2,117,131
60,23,117,131
30,15,117,131
25,89,117,131
我知道CSV 渲染器在 SSRS 2008 R2 中经历了重大变化,支持图表和仪表,更重要的是它提供了 2 种模式:默认Excel
模式和Compliant
模式。但是这两种模式都不能解决这个问题。Compliant 模式应该最接近 2005 年的模式,但显然它对我的情况来说还不够接近。
我的问题:
有没有办法强制 SSRS 2008 将报告回退到向后兼容模式,以便导出为 2005 CSV 格式?
尝试的解决方案:
a) 使用基于 2005 的 CRI
根据这篇关于 ExecutionLog2的文章,如果 SSRS 2008 R2 遇到无法自动升级的报告(例如,使用基于 2005 的 CustomReportItem 控件构建的报告),那些特定的报告将是以“透明的向后兼容模式”使用旧的育空引擎进行处理。
似乎它回到了以前的版本模式(2005)并尝试渲染它。所以我尝试使用基于 2005 的条形码 CustomReportItem 并部署到 SSRS 2008 R2 报表服务器,但它显示的结果与以前相同,尽管它抑制了条形码。这是因为 SSRS 2008 R2 找到了一种方法来抑制部分报告输出并显示其余部分。很高兴找到一个基于 2005 年的 CRI,它可以让 SSRS 2008 R2 使用其旧的 Yukon 引擎对其进行处理。请注意,很可能,即使它使用“旧育空处理引擎”,它仍可能使用新的 CSV 渲染器,因此它显示相同的输出。如果这是真的,那么这个选项是没有实际意义的。
b) 使用 XML 渲染器
我们可以使用自定义 XML 渲染器,然后使用 XSLT 将 xml 转换为适当的 CSV,但这意味着我们需要转换所有 200 个报告。因此这是不可行的。
请注意,我们无法选择并排部署 SSRS 2005 和 SSRS 2008 R2。