To：Henrryzhang(North Wolf) 在某些情况下，只关闭连接对象并不会自动将与其关联的记录集对象。 例如： Recordset.CursorType = adOpenStatic Recordset.CursorLocation = adUseClient Recordset.LockType = adLockBatchOptimisticSet Recordset.ActiveConnection = Nothing Connection.ClosePRINT Recordset.State＝＝＝＝＝ ＝＝＝＝＝ To every body ＝＝＝＝＝ ＝＝＝＝＝ .Close 与 Set ... = Nothing 不应该混合处理，他们是两个不同的概念。关于 Nothing 的详细机理，请各位参考一下COM中的相关内容。（http://www.ilook100.net/SWTech.html）就算ADO默认情况下，能够在记录集对象被Nothing时会自动调用其Close方法，但我也强烈建议大家不要依赖ADO的这种特性！！！ 无论如何，自己显示关闭Recordset/Connection对象总是件值得的事情，至于它们是否会浪费你多少的系统资源，这不应该是个要商榷的问题，因为这永远都不会是造成你系统效率低下的原因，还是去另寻值得你优化的地方罢～ *^_^*另外，关于Connection对象的生存期问题。我建议，大家不要使用一个全局的Connection，这样很耗连接资源，在多用户并发时更凸现问题。在使用COM+环境中，系统会帮助你使用连接池，大家无需担心反复创建连接对象的开销。不过关于这个问题与COM+的一些特性，本人才浅手笨，一时说不清楚。总之，我建议大家还是对COM/COM+多点了解罢，这样在做多层结构的应用系统时候，才会多点自信了！好了，今天就罗嗦这么多了，给分罢——老板！
我个人的习惯if not rs is nothing then if rs.state=1 then rs.close end if set rs=nothing end if至于其他问题，楼上很清楚了，无须多言
记录集只要没有用 Set rs = new Adodb.recordset就会在退出作用域时自动释放内存了。funtion rsOpen(strSQL as string,conOpen as adodb.Connection) as adodb.recordset dim recTemp as adodb.recordeset set recTemp = new adodb.recoordset rsTemp.Open strSql, conOpen, adOpenKeyset, adLockReadOnly Set rsOpen = rsTemp end functiondim recWare as adodb.recordset set recWare = rsopen("Select * from ware",connnection)
一定要Close and Set nothing。你的程序不关闭表现的速度是由于你的程序太小，和机器太快的原因。如果是一个大的应用，这样不关闭会把你机器累死的。当然Access数据库对大量数据无法处理，我的经验是超过1G的话，这家伙就基本上发疯死掉了。当然!G也是用户数据。 如果程序处理的数据规模小，倒是无所谓。本人原则之一，永远不去优化本来不算慢的程序（懒吧），即使这样，大数据量的话还是要经常需要优化
建议楼主看看COM,你就会明白了 new 一个 Recordset实际上是建立了一个对 _RecordsetPtr 智能指针的引用 调用 _Recordset 接口的 AddRef() close() 方法则是调用接口相应的 Release() Set nothing 会调用类厂的 CoUnInitialize() 释放COM 资源理论上智能指针会负责对象的生存周期,但是建议还是要显式调用,它不可能太"智能"。
请教 dim recTemp as adodb.recordeset set recTemp = new adodb.recoordset 与 dim recTemp as new adodb.recordest 有什么不同？
回复人： l_tiger(小大虫) 请教 dim recTemp as adodb.recordeset set recTemp = new adodb.recoordset 与 dim recTemp as new adodb.recordest 有什么不同？不光是显式隐式的调用问题,第2种方法在VB中有漏洞,具体什么样的忘了,似乎是对象释放不完全.
Option ExplicitPrivate AdoRs1 As ADODB.Recordset Private AdoRs2 As New ADODB.RecordsetPrivate Sub CmdTest_Click() 'Step1: 新建一个ADODB.RecordSet实例； 注意 AdoRs2不需要新建
如果你觉得用mrc.close+set mrc=nothing占用时间的话，
那就可以不用mrc.close+set mrc=nothing
直接将CONNECTION.close
压缩完之后再CONNECTION.open
就行了，
我现在是这样做的
┏━★━━◆━━★━┓
♂欢|◢ＣＳＤＮ◣|使♂ ▲自由保存帖子，浏览，关注检测
┃迎|◥论坛助手◤|用┃ ▲完善的ＣＳＤＮ客户端工具
┗━☆━━◇━━━☆┛ ▲自动添加签名......让你更快，更爽，更方便地上CSDN...
http://www.csdn.net/expert/topic/573/573604.xml
http://www.chinaok.net/csdn/csdn.zip
窗体级的可以不管，但是为了统一，我建议还是应该显示的释放。
另外，你的这个ExecuteSQL里没有必要每次都声明Connection和Recordset对象，不妨声明为模块级，这样就不用频繁的创建和释放对象了。
特别是Connection对象，按照我的一般习惯就是声明成模块级的Public，在Sub Main里就建立连接，直到整个应用程序结束前才关闭并释放。
2.若此函数不常使用则Recordset对像不关闭而运行下面的程序。则占用的内存过大。必耗去大量内存资源。
3.Recordset关闭是必然的，不要想着Recordset.close将占去一点时间。你想过没有。若不闭。若内存不够。OS则为了你下面的程序运行。而把硬盘当做内存。进行页换入和换出的。将花太比Recordset.close还多得多的时间。若用不着Recordset.close.MS就不会给你Recordset的close.MS给Recoreset就是说明你要用它。没用。当然不用给出来。。
在某些情况下，只关闭连接对象并不会自动将与其关联的记录集对象。
例如：
Recordset.CursorType = adOpenStatic
Recordset.CursorLocation = adUseClient
Recordset.LockType = adLockBatchOptimisticSet Recordset.ActiveConnection = Nothing
Connection.ClosePRINT Recordset.State＝＝＝＝＝ ＝＝＝＝＝ To every body ＝＝＝＝＝ ＝＝＝＝＝
.Close 与 Set ... = Nothing 不应该混合处理，他们是两个不同的概念。关于 Nothing 的详细机理，请各位参考一下COM中的相关内容。（http://www.ilook100.net/SWTech.html）就算ADO默认情况下，能够在记录集对象被Nothing时会自动调用其Close方法，但我也强烈建议大家不要依赖ADO的这种特性！！！
无论如何，自己显示关闭Recordset/Connection对象总是件值得的事情，至于它们是否会浪费你多少的系统资源，这不应该是个要商榷的问题，因为这永远都不会是造成你系统效率低下的原因，还是去另寻值得你优化的地方罢～ *^_^*另外，关于Connection对象的生存期问题。我建议，大家不要使用一个全局的Connection，这样很耗连接资源，在多用户并发时更凸现问题。在使用COM+环境中，系统会帮助你使用连接池，大家无需担心反复创建连接对象的开销。不过关于这个问题与COM+的一些特性，本人才浅手笨，一时说不清楚。总之，我建议大家还是对COM/COM+多点了解罢，这样在做多层结构的应用系统时候，才会多点自信了！好了，今天就罗嗦这么多了，给分罢——老板！
我个人的习惯if not rs is nothing then
if rs.state=1 then
rs.close
end if
set rs=nothing
end if至于其他问题，楼上很清楚了，无须多言
dim recTemp as adodb.recordeset
set recTemp = new adodb.recoordset
rsTemp.Open strSql, conOpen, adOpenKeyset, adLockReadOnly
Set rsOpen = rsTemp
end functiondim recWare as adodb.recordset
set recWare = rsopen("Select * from ware",connnection)
如果程序处理的数据规模小，倒是无所谓。本人原则之一，永远不去优化本来不算慢的程序（懒吧），即使这样，大数据量的话还是要经常需要优化
new 一个 Recordset实际上是建立了一个对 _RecordsetPtr 智能指针的引用
调用 _Recordset 接口的 AddRef()
close() 方法则是调用接口相应的 Release()
Set nothing 会调用类厂的 CoUnInitialize() 释放COM 资源理论上智能指针会负责对象的生存周期,但是建议还是要显式调用,它不可能太"智能"。
dim recTemp as adodb.recordeset
set recTemp = new adodb.recoordset
与
dim recTemp as new adodb.recordest
有什么不同？
第一段代码显式的创建了对象
第二段代码中，只有recTemp第一次被调用的时候才会创建建议是用第一段代码，这样可以控制对象的创建，还可以避免因为内存不足而造成的对象创建失败时出现莫名其妙的错误。对于楼主，操纵本地的Access。我建议把数据库访问封装到一个DLL中，这样也可以便于重用。不建议同时打开3个以上的Recrodset。通常来说，Recordset主要是用于呈现数据，对于数据的操作则主要用存储过程或者SQL语句来实现。同时打开几百个Recordset只有Web服务器才需偶尔要这样做（一旦页面生成完毕会立即释放），而通常对于Web服务器，我们会将Recordset加以缓存并池化以减少并发数目。同时打开几百个Recordset必将导致效率问题，同时在多用户环境下会对服务器造成极大压力。
请教
dim recTemp as adodb.recordeset
set recTemp = new adodb.recoordset
与
dim recTemp as new adodb.recordest
有什么不同？不光是显式隐式的调用问题,第2种方法在VB中有漏洞,具体什么样的忘了,似乎是对象释放不完全.
Private AdoRs2 As New ADODB.RecordsetPrivate Sub CmdTest_Click()
'Step1: 新建一个ADODB.RecordSet实例； 注意 AdoRs2不需要新建
Set AdoRs1 = New ADODB.Recordset
'Step2: 执行某些操作
MsgBox "AdoRs1字段个数 :" & AdoRs1.Fields.Count
MsgBox "AdoRs2字段个数 :" & AdoRs2.Fields.Count
'Step3: 释放RecordSet
If AdoRs1.State = adStateOpen Then
AdoRs1.Close
End If
Set AdoRs1 = Nothing
If AdoRs2.State = adStateOpen Then
AdoRs2.Close
End If
Set AdoRs2 = Nothing
'Step4: 测试被释放后的RecordSet (注意测试的顺序)
If AdoRs1 Is Nothing Then
MsgBox "AdoRs1 被完全释放 !"
Else
MsgBox "AdoRs1 没有被完全释放 !"
End If
If AdoRs2 Is Nothing Then
MsgBox "AdoRs2 被完全释放 !"
Else
MsgBox "AdoRs2 没有被完全释放 !"
End If
MsgBox "AdoRs2字段个数 :" & AdoRs2.Fields.Count
MsgBox "AdoRs1字段个数 :" & AdoRs1.Fields.Count
End Sub '经过以上测试后, 我们发现一个有趣的现象:
'AdoRs1被释放后不能读取AdoRs1的某些属性 , 必须重新执行
'Set AdoRs1 = New ADODB.Recordset 方可使用某些属性
'这样可能造成某些不方便
'AdoRs2被释放后仍然能读取AdoRs2的某些属性
'这样是否会造成资源没有被完全释放。
'希望大家能对该问题进行一些讨论和指教，我觉得这个问题才是关系到系统资源的关键之所在。谢谢。
你好！
我并不是同时打开几百个recordset，而是定义了几百个recordset，会在不同的时段调用。