在将其设置为空之前，是否需要关闭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

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

  

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

     

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

     

您未创建的ADO对象（尤其是Connection对象）未明确发布。显式释放您创建的对象只是一种很好的编程习惯。如果您分配内存，请将其释放。根据您使用的语言，让变量超出范围可能会也可能不会导致它被释放。

请参阅Pooling in the Microsoft Data Access Components

如果.Net Interop涉及的任何机会都要警惕：有很多关于由于在.Net的垃圾收集下发生COM对象（或包含对象）的懒惰方式引起的问题的警告。

Answer 4

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

fsT.Close

之后

fsT.Open

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