更新报告中的数据：任何潜在的陷阱？

Question

题：

一般而言，更新 SSRS 报告中的数据是否存在任何陷阱？*

语境：

更具体地说，我正在谈论这种情况：

• SSRS 2008（如果需要，可以选择升级）。
• MSSQL 2008（如果需要，可以选择升级）。
• Web.forms ReportViewer 2010 在我们自己的 ASP.NET 应用程序中。

我只需要做一个小的数据库更新。用户可以勾选一个复选框参数“我要打印这个”，这将做一个小的更新或插入以标记报告已在特定时间点运行。该报告将仅显示自上次“打印”运行以来添加的项目，因此我基于此过滤我的 WHERE 子句，仅向用户提供“新”项目。

我担心的原因是，从主要用于查看数据的工具进行更新“感觉不对”。另一方面，像上面一样小的东西似乎是最简单的解决方案。

具体问题：

以下是我正在寻求洞察力的一些具体问题：

• 安全性：报告的连接需要与允许插入的用户一起运行，更明智的默认设置是为仅选择用户运行它？SSRS 是否有已知的类似 sql 注入的攻击？
• 可用性：我想根据用户是否勾选复选框来进行更新。我不确定这对刷新的效果如何，以及您是否可以在执行查询时检测到渲染格式是什么（这将允许我使复选框仅在 - 例如 - PDF 导出时触发更新）。
• 健壮性：更新语句似乎更容易出现异常（违反约束等）。不确定是否有一种优雅的方法来防止、记录、跟踪和调试这类问题。

Answer 1

老实说，不要这样做。是的，可以通过在报告中声明一个全局变量，然后将其传递给生成结果集的语句来在返回数据之前进行一些处理，但这充其量是混乱且不明智的。这就是说您将来不想向报告中添加更多变量？此时，它在技术上变成了一种表单 - 这就是 ASP.NET 的设计目的 - 而不是 SSRS/ReportViewer 的设计目的。

您说您正在 ASP.NET Web 应用程序中使用报表查看器 - 因此我的建议是，如果可以的话，在应用程序本身中处理打印逻辑，并让报表发挥它最擅长的作用。我们公司有一个应用程序，它以类似的方式生成报告 - 我们需要跟踪谁在打印报告以及何时打印报告 - 我们通过禁用报告中的打印功能来实现这一点，然后在应用程序中提供功能来呈现报告报告为 PDF 格式，然后打印。这使我们能够非常灵活地跟踪/审计内容以及报告的生成方式和打印位置。

此外，从长远来看，将两部分逻辑分开会更好 - 例如，如果您需要更改报告，这可以在应用程序外部完成，然后您只需提供 rdl 文件并替换旧文件即可。在报告中放入代码来更改数据意味着额外的测试并模糊了职责的界限。

此外，正如您上面提到的 - 数据可能会以某种方式受到损害（SQL 注入等），并且让应用程序验证输入是迄今为止正确的做法 - 更不用说添加所有额外的内容SQL 需要验证、更新然后返回数据，这会降低报告速度。如果您只有几个用户，这可能看起来没什么，但如果您的用户群很大，则可能会导致问题。

这似乎是目前最快的解决方案，但这不一定是正确的解决方案。保持简单和分离，从长远来看，你会发现问题会少很多。

我希望这有帮助。