ado|对象在真实的生活里,程序员天生懒惰. 这个事实使我们经常深陷BUG的泥塘. 尤其是当用ASP处理数据库连接时,它将让你感觉身处油锅.

在ASP里,我们建立数据库连接,然后用ADO获得数据查询的结果; 我们最常用到的是ADODB.Connection和ADODB.Recordset. 让我们看一个简单的例子来了解一下如何使用这两个对象:

Dim objConn
Set objConn = Server.CreateObject("ADODB.Connection")
objConn.ConnectionString = "DSN=Northwind"
objConn.Open
Dim objRS
Set objRS = Server.CreateObject("ADODB.Recordset")
objRS.Open "SELECT * FROM Table1", objConn

如果你还不是很熟悉数据库连接的话,请先阅读这篇文章
(http://www.4guysfromrolla.com/webtech/faq/Databases/faq2.shtml).

我们从objRS开始讨论我们的主题. 当我们用完objRS之后会做些甚麽呢? 通常情况下程序员不再进行任何操作,他们让ASP去料理后事. 当Server.CreateObject调用发生后,服务器将分配资源来操作这些对象的新实例(instances),如果我们不显式地通知服务器我们不再使用这些分配的资源了,ASP应该为我们释放这些资源. 对ASP完全信任有点儿冒险. 更安全和更可信的办法是显式地关闭和清除我们的Recordset和
Connection对象的实例.

我们该怎么关闭我们的对象及释放掉所分配的内存呢? 我们所要做的全部事情就是当我们用完这两个对象后调用以下的四行代码:

objRS.Close
Set objRS = Nothing
objConn.Close
Set objConn = Nothing

这样将强制释放资源,远胜过依赖ASP隐式地自动释放. 现在,你可能会有些疑惑:我们这么做真的很重要吗? 谁会在每个用过数据库连接的ASP页面里多写四行代码呢? 这样做的好处远远超过多写四行代码给我们带来的负担. 让我们引用
ActiveServerPages.com(http://www.activeserverpages.com/)的站长的一些话:

"你应该关闭Recordset,设为Nothing,关闭Connection,用同样的次序将其设为
Nothing. 标准的资源碎片收集是不完全的和不可信的.[前面提到的碎片收
集,Charles指的是隐式地清除服务器分配的资源.]

"DataReturn[一个ASP webhosting公司]有许多站点依赖IIS自动进行碎片收集时出现可怕的错误. 在加上Close/Set Nothing的几行代码后,这些站点又象马儿一样欢快地跑起来. 所有的大站都有显式释放资源的硬性规定."

如果Charles的话还不能让你信服,让我们来讨论一个由于没有显式使用内存再分配而出现的问题,这是个真实的例子. Brian Fairchild用Access做后台数据库来支持一个ASP大站. 他发现每过一阵子时间,ASP页面就会完全停止相应! HTML页能正常显示,但所有的ASP页面完全瘫痪,系统不得不重启. 最后,Brian发现,显式地关闭和释放Recordset和Connection对象,故障就全部消失了. (看看消息板上Brian谈及此故障的文章)(http://www.aspmessageboard.com/forum/performance.asp?
M=1321&P=1&F=23)

Charles Carroll还告诉我们一个技巧,那些用Access的用户应该增加缺省的线程数目. 这儿就是Charles所说的:

"注册表里Access缺省的线程数是4. 把它加到20将会使服务器跑得出乎寻常的顺畅, 但只是对Access特别管用,我们的服务器的CPU占用率从上午8点到晚上5点都是100%,但我在增加了线程数以后,服务器上的CPU马上凉快了下来."