整套报告在SSRS 2005生产中运行良好，在SSRS 2008 R2 SP2 Dev / UAT区域仍然正常，但在新的生产服务器上，其中两个报告立即失败（不是超时问题！）以下错误：
An error occurred within the report server database. This may be due to a connection failure, timeout or low disk condition within the database. (rsReportServerDatabaseError)
A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The specified network name is no longer available.)
这两个报告与其他报告在访问数据库（使用单个共享数据源）或查询数据（嵌入式SQL）的方式上似乎没有任何差异。他们的SQL语句在设计/运行查询模式下工作正常，并且像其他报告一样立即返回。报告在开发机器上的BIDS和prod机器中的ReportBuilder都可以正常工作。
在我们上传所有这些内容之后，有几次与另一份报告有相同但间歇性的问题，但我现在已经不能再复制一周了。
从那时起，我重新创建了一个全新的SSRS数据库，数据源，从UAT下载报告，并将其上传到新服务器，在此服务器中，即使显示参数面板也会失败。
尝试以下内容但没有成功：
通过打开SSRS详细调试，我收集了日志，发现当调用报告时，它成功执行了一个数据集为2，然后失败并出现上述错误，而不再在日志中写入任何条目。从详细日志来看，它甚至似乎都没有尝试执行第二个数据集。
除了超时/空间不足之外，这种类型的失败还有其他原因吗？
答案 0 :(得分：0)
在对2个有问题的报告进行了大量的报道之后，看到它们与实际的报告数据源差异非常相似，我终于被批准了额外的时间从头开始重新创建它们。
我首先只创建参数并将其值转储到报表上。然后我添加了一个数据集。测试报告仍然有效。其中一个参数最初是基于查询的多选和隐藏。它用于使用参数值数组查找英语到法语的翻译值。这显然是一个黑客攻击，但是，这十多年来这十几个报告都有效。一旦我将参数配置为使用数据集作为可用值，就会重现上面的错误。
由于我从未设计过这样的查找方式，因此我完全删除了基于查询的隐藏参数，并将所有单元格更改为使用它进行查找，直接在基础数据集上使用Lookup()函数。
报告现在有效。我们没有触及剩下的报告，他们仍在使用“黑客”。去了解SSRS对这两者不喜欢的事情。