我将Microsoft Access 2007与IBM AS400 DB2 SQL v6r1服务器一起使用。最近，我开始通过将一些更复杂的Access查询转换为Pass-Through类型来扩展我的DB2体验。查询速度的提高是惊人的，但是预计会有所增加，特别是在我们较大的表中，有些行有20,000,000多行。
正如人们对Access + DB2所期望的那样，我已经遇到了SQL0666错误。或者至少......我现在期待它，因为我已经遇到了很多。我已经应用了自助，并通过增加“ODBC超时”来解决了这个问题。传递查询的属性。我发现看起来像是一个逻辑上安全的值，直到查询工作，然后加倍它。
无论Access如何计算其对查询持续时间的估计，它似乎与现实完全不成比例。如果我将这样的查询复制/粘贴到IBM iNavigator SQL窗口并在那里运行，则需要花费一小部分时间，有时甚至是Access认为应该花费的1/10。
昨天我偶然发现了以下网页，该网页描述了完全删除查询超时问题的步骤。我发现它添加了“QUERYTIMEOUT = 0＆＃39;到DSN，这似乎是对SQL0666错误的永久性解决方法。
https://kb.rfgen.com/kb/index.php?View=entry&EntryID=107
但是...
这不危险吗？
一个失控的查询可以浸泡服务器，直到每个人都尖叫或崩溃..？
是否有另一个更深的超时限制来防止失控进程..？
我很想把它添加到我的所有疑问中，但作为一个关心的书呆子，我对此犹豫不决。
答案 0 :(得分：1)
执行查询运行时估计的不是Access - 它是iSeries优化器本身的Db2。
有几个级别可以设置超时，如this technote中所述，但ODBC设置会覆盖它们。
您的预订正确：超时的目的正是为了防止“失控”查询消耗太多资源。使用现代硬件崩溃服务器的风险可能很小，但并发用户查询的性能肯定会受到影响。
您可能希望与服务器管理员联系，以确定环境中可能存在的最大超时值，并在数据源定义中使用它。