相关疑难解决方法(0)

首先，我明白运行超大/长时间运行的报告是一个可怕的想法。我知道 Microsoft 有一个经验法则，规定 SSRS 报告的执行时间不应超过 30 秒。然而，由于外部力量，例如遵守州法律，有时庞大的报告是首选的邪恶。

在我工作的地方，我们有一个从 Crystal Reports 迁移到 SSRS 的 asp.net (2.0) 应用程序。由于庞大的用户群和复杂的报告 UI 要求，我们有一组屏幕可以接受用户输入的参数并创建要在夜间运行的计划。由于应用程序支持多个报告框架，我们不使用 SSRS 的调度/快照功能。系统中的所有报告均由预定的控制台应用程序生成，该应用程序采用用户输入的参数，并使用创建报告时使用的相应报告解决方案生成报告。对于 SSRS 报告，控制台应用程序生成 SSRS 报告并通过 SSRS Web 服务 API 将它们导出为 PDF。

到目前为止，SSRS 比 Crystal 更容易处理，除了我们最近从 Crystal 报告转换为 SSRS 的某个 25,000 页的报告之外。SSRS 服务器是 64 位 2003 服务器，有 32 gigs 的运行 SSRS 2005 的内存。我们所有的小报告都工作得非常好，但是我们在处理像这个这样的大报告时遇到了麻烦。不幸的是，我们似乎无法通过 Web 服务 API 生成预测报告。生成/导出大约 30-35 分钟后会出现以下错误：

异常消息：基础连接已关闭：接收时发生意外错误。

Web 服务调用是我相信你们以前都见过的：

data = rs.Render(this.ReportPath, this.ExportFormat, null, deviceInfo,
   selectedParameters, null, null, out encoding, out mimeType, out usedParameters, 
   out warnings, out streamIds);

奇怪的是，如果使用报表管理器直接在报表服务器上运行报表，则该报表将运行/呈现/导出。为报告生成数据的过程运行大约 …