Sql server 计算机进入睡眠状态后，vb6应用程序中与sql server数据库的连接丢失

我有一个旧的visual basic 6应用程序，当计算机从睡眠状态恢复时，一些用户报告了我的错误。这个问题并不是在每台客户端计算机上都会发生（我想说的是一些Windows7）。如果vb6应用程序仍处于打开状态，则如果他们尝试使用此应用程序，它将崩溃，并显示以下错误消息

我调试后发现了问题：我有一个全局变量，用于保持与数据库的连接。此变量仅在应用程序开始时初始化一次。当计算机进入睡眠状态并在几次之后返回时，此变量的状态仍然为“打开”，但实际上连接已断开！如果我先“关闭”然后“打开”这个变量连接，我就可以查询数据库了

我想知道我失去数据库连接是否正常

下面是一些代码：

 ' This is my global variable
 Global cn As New ADODB.Connection

 ' Set connection properties for sql server.
 cn.ConnectionTimeout = 25
 cn.Provider = "sqloledb"
 cn.Properties("Data Source").Value = ".\SQL2008"
 cn.Properties("Initial Catalog").Value = DB_INITIAL_CATALOG
 cn.Properties("User ID").Value = DB_USERNAME
 cn.Properties("Password").Value = DB_PASSWORD
 cn.Open

 ' This is a typical query on my database
 Set rs = New ADODB.Recordset
 strSql = "SELECT * FROM tblUsers"
 rs.Open strSql, cn, adOpenKeyset

有什么想法吗

---

谢谢。

是的，我以前见过这种东西。连接字符串上的设置可能有助于减少连接，但超时和/或网络断开可能会中断与DB服务器的底层（通常是TCP）连接。然后，您将在数据库的下一个I/O中看到错误清单本身

我建议包装对共享连接的访问，以便您可以透明地捕获该特定错误并重试。在类或模块中保持连接私有，并使用以下方法：

'Open is called to set the args to connect, these should be saved for reconnect
Public Sub Open(connect params here)

    'save arsg to prive members to reconnect

    'connect to db

End Sub

Public Function OpenKeyset(sql) As RecordSet

   Set rs = New ADODB.Recordset  

   On Error Resume Next
   rs.Open strSql, privateConn, adOpenKeyset

   'if the error is the disconnect
   If Error.Number = xxx Then 'or inspect the error message or error collection

      'turn of error trap
      Err.Clear
      On Error Goto 0

      'reopen db conn

      'then retry
      rs.Open strSql, privateConn, adOpenKeyset

   End If

   OpenKeyset = rs

End Function

---

您甚至可以定期执行no-op-db操作，如查询目录或其他任何操作，以保持连接处于活动状态并重新连接。如果计算机处于休眠状态，您还可以观察发生的时间跳变。

您应该在vb6代码中捕获睡眠和唤醒事件，任何长时间运行的查询都应该在睡眠时关闭，以便关闭dB连接。在唤醒时，你会做相反的事情。你需要听我说 WM_POWERBROADCAST消息

祝你好运

---

杰普

感谢您的回复。我似乎很奇怪出现了这种问题，你不觉得吗？我认为这种解决方法不是很优雅，我希望有一个更专业的解决方案。我的“临时”解决方案与您的解决方案相差不远：在查询数据库之前，我会对数据库进行假选择，如果由于特定错误而失败，则会关闭并重新启动数据库连接。计算机进入睡眠状态时，TCP/IP连接都会断开。由使用它们的软件检查并修复断开的连接。这并不罕见。