解决方案:重新启动SSMS。
我可以在SSMS 13.0.16106.4 / SQL Server 13.0.4206.0上复现这个错误(尽管报告在一段时间内能正常工作,但问题又出现了)。
使用相同的SQL用户,在运行SSMS 12.0.5000.0的远程桌面上,报告正常。
另一个使用SSMS 14.0.17177.0的用户从未遇到过此问题。
重启服务器没有效果。
我重启了SSMS 13.0.16106.4,问题得以解决。这可能是一个SSMS内存问题。
使用Microsoft SQL Server Management Studio 14.0.17285.0时出现问题,通过关闭并重新启动SSMS解决。
我遇到了完全相同的问题,最初认为是使用最新的Windows 10上的SSMS包 - 版本17.1 - 导致的,但其他使用相同设置的人没有出现错误。
然后我运行了SSRS的配置(已安装但未配置)。这创建了报告服务器数据库,但没有改变情况。我不认为SSIS报告会使用SSRS,但也不确定。
然后我运行了Windows更新,并安装了最新的.NET 4.7程序包。
重新启动后,SSIS报告恢复正常!
因此,我所做的一个或多个操作再加上重新启动产生了影响,但同样可能只是需要重新启动。
这是在我的开发机器上,我一直在从生产环境备份和还原SSISDB到我的开发环境中 - 这可能与尝试重新生成此问题有关,但自从完全删除和恢复SSISDB以来,我就没有遇到这个问题。
希望这可以帮助?
回复:来自@James Bourne的“我重启了SSMS 13.0.16106.4,问题解决了。这可能是一个SSMS内存问题。”
回复:来自@Ade的“使用SSMS Microsoft SQL Server Management Studio 14.0.17285.0。通过关闭SSMS并重新启动解决了这个问题。”
我在几个SSMS选项卡中打开了一些非常大的nHibernate查询(从扩展事件中捕获)。我关闭了每个选项卡,并重新启动了SSMS 18.8版本。
问题解决!
我曾经遇到过这个问题。结果发现我从数据库中删除了一些Windows组(该数据库位于完全不同的服务器上),当我将它们添加回去后,报告就可以正常工作了,也不再显示#error
当然,这毫无意义,但我想记录下来,以防有所帮助或唤起某人的记忆。