从 .Net 应用程序运行 ADOMD.Net 命令时，我遇到了一个神秘的 XMLA 超时错误。Visual Basic 例程遍历驻留在 SQL Server Analysis Services 2014 实例上的挖掘模型列表，并对每个模型执行交叉验证测试。每当交叉验证测试经过的时间达到 60 分钟标记时，XML for Analysis 解析器就会抛出一个错误，指出请求超时。对于花费不到一小时的任何日常操作，我可以使用相同的 ADOMD.Net 连接与相同的服务器和应用程序，而不会出现任何故障。这种情况的罪魁祸首往往是服务器上的 ExternalCommandTimeout 设置，默认为 3600 秒，即一小时。但是，在这种情况下，服务器上的所有以下超时属性都设置为零：CommitTimeout、ExternalCommandTimeout、ExternalConnectionTimeout、ForceCommitTimeout、IdleConnectionTimeout、IdleOrphanSessionTimeout、MaxIdleSessionTimeout 和 ServerTimeout。只有三个可用的超时属性，没有一个设置为一小时：MinldleSessionTimeout（当前为 2700）、DatabaseConnectionPoolConnectTimeout（现在为 60 秒）和 DatabaseConnectionPoolTimeout（为 120000）。MSDN 文档列出了另外三个在 SQL Server Management Studio 2017 中选中的高级属性不可见的超时属性：AdminTimeout、DefaultLockTimeoutMS 和 DatabaseConnectionPoolGeneralTimeout。前两个默认为无超时，第三个默认为一分钟。MSDN 还提到了一些“禁止”超时属性，例如 SocketOptions\ LingerTimeout、InitialConnectTimeout、ServerReceiveTimeout、ServerSendTimeout、其中都带有警告，“您不应该更改的高级属性，除非在 Microsoft 支持的指导下。” 不过，我看不到任何通过 SSMS 2017 GUI 设置这些的方法。
由于我真的用完了超时设置来尝试，我很难过如何纠正这种行为并允许我的 .Net 应用程序通过 ADOMD 等待这些交叉验证。很久以前，我能够通过将某些属性设置附加到连接字符串来解决一些神秘的 SSAS 超时问题，例如“Connect Timeout=0;CommitTimeout=0;Timeout=0”等等。然而，尝试以这种方式通过连接字符串分配 ExternalCommandTimeout 值会导致 XMLA 错误“无法识别 ExternalCommandTimeout 属性”。我没有以这种方式测试每一个 SSAS 服务器超时，但是这个异常表明 ADOMD.Net 连接字符串只能接受超时属性的一个子集。
我在某处错过了超时设置吗？有没有人知道还有什么可能导致这种深奥的错误？提前致谢。我已经尽可能长时间地把这个问题放在次要位置，并且现在真的需要修复它。我想知道 ADOMD.Net 是否有自己单独的超时设置，可能有不同的名称，但我找不到任何相关的文档......