在将 ADODB.Recordset 对象设置为空之前是否有必要将其关闭？

Question

Dim rs as ADODB.Recordset
set rs = ReturnARecordset 'assume ReturnARecordset does just that...

'do something with rs

rs.Close
set rs = Nothing

设置为空之前是否需要先调用rs.Close？

编辑：我们有一个全局连接，在应用程序运行期间保持打开状态，并且所有记录集对象都使用同一连接。我在下面看到两个答案，讨论需要关闭记录集以确保连接不会保持打开状态。对我来说，这听起来像是很多愚蠢的谈话，因为连接是由连接对象控制的，而不是记录集对象，对吗？但如果我在这里遗漏了什么，请告诉我......

Answer 1

显式调用

Close

的唯一原因是当您不确定记录集是否从项目中的其他位置引用时，通常是一些草率编码的结果。

Dim rs as ADODB.Recordset
Set rs = ReturnARecordset
...
MyControl.ObscureMethod rs
...
Set rs = Nothing

最后一行应该终止记录集实例，而不显式调用

Close

，除非

MyControl

持有额外的引用，从而阻止正常的拆卸。在

Close

上调用

rs

将确保

MyControl

无法将其引用用于任何有用的事情，同时会在火焰中崩溃。

Answer 2

是的，这不仅仅是强制垃圾收集，它还告诉服务器连接正在终止，这避免了多个打开的孤立连接（它们最终会自行超时），但关闭它们始终是最佳实践。

当 ADODB 使用远程连接而不是本地连接时，这一点尤其明显。

Answer 3

我需要写很多文件。如果我在写入每个文件后没有关闭连接，那么我会在后续文件的末尾收到无关的垃圾。

fsT.Close

随后

fsT.Open

“刷新”输出流。所以当我保存一个新文件时，它是“干净的”。

Answer 4

您可能会遇到 ODBC 或 OLEDB 池问题，这些问题会保持连接打开并占用池插槽：

连接蠕变的常见原因包括：

ADO Connection 和 Recordset 对象实际上并未关闭。如果您不明确关闭它们，它们将不会被释放到池中。这可能是连接蠕变的最常见原因。

您创建的 ADO 对象（尤其是 Connection 对象）未显式释放。显式释放您创建的对象只是良好的编程实践。如果分配了内存，请释放它。根据您使用的语言，让变量超出范围可能会也可能不会导致它被释放。

请参阅 Microsoft 数据访问组件中的池化

如果有任何涉及 .Net Interop 的机会，请小心：有很多关于由于在 .Net 垃圾收集下发生 COM 对象（或包含的对象）释放的惰性方式而导致的问题的警告。