4

我们公司有一堆 VB6 应用程序。我们正在尝试调试随机 SQL 超时错误，并使用 SQL Server Profiler 对 Audit Login 事件进行跟踪。我们注意到连接是非池化的。我们将 SQLOLEDB 提供程序与 SQL Server 2000 和 2005 一起使用。我搜索了互联网，我遇到的所有内容都说默认情况下连接在 SQLOLEDB 提供程序中汇集，但我们没有看到这一点。下面是我们用来连接数据库的代码。我们确实需要将这些连接池化，因为我们认为这可能是我们的随机超时错误的问题。任何人都可以阐明为什么连接池不起作用以及使它起作用的任何方法吗？谢谢。

Dim cnn As New ADODB.Connection
cnn.ConnectionString = "Provider=SQLOLEDB;Data Source=xxx;Catalog=xxx;User ID=xxx Password=xxx;"
Call cnn.Open
Dim cmd As New ADODB.Command
Set cmd.ActiveConnection = cnn
cmd.CommandText = "SELECT * FROM [Table]"
Dim rs As New ADODB.RecordSet
Call rs.Open(cmd, , adOpenStatic, adLockOptimistic)
While Not rs.eof
    'Do stuff
    Call rs.MoveNext
Wend
'Close and Dispose connection here
4

3 回答 3

5

在每次调用时处理连接可能会阻止池

...至少为每个唯一用户实例化一个 Connection 对象实例——始终如此。否则，当该字符串的最后一个 Connection 对象关闭时，池将被销毁。

http://msdn.microsoft.com/en-us/library/ms810829.aspx

于 2009-01-09T13:29:25.540 回答
0

我搞砸了，在应用程序启动时打开了一个连接，并在应用程序运行的整个过程中保持打开状态。连接池确实在第二个打开和关闭的连接之后开始。

于 2009-01-09T19:04:53.130 回答
0

您提到您正在尝试追踪随机超时问题。我也有同样的情况，通常是当我做一个返回很多行的 SELECT 时。两件事情：

Cnn.CursorLocation=ADODB.adUseServer

（另一个选项是adUseClient） - 我相信adUseServer给了我更快的查询，这减少了超时的可能性。我相信你在打开连接之前就这样做了。

Cnn.CommandTimeout=0

同样在open(), 之前告诉它你想要一个无限的超时。我认为默认超时时间大约是 30 秒，这对于某些查询来说太短了。将CommandTimeout用于Recordset查询。如果您使用一个Command对象，它有它自己的CommandTimeout成员，它似乎不会从 Connection 继承（即，我在执行命令之前设置它）。

抱歉，如果语法不太正确，我将删除一些 C++ 代码。

于 2009-01-09T19:40:00.657 回答