\"＜ TD ＞\" & objRS(\"ShippedDate\") & \"＜ /TD ＞\" & _
\"＜ TD ＞\" & objRS(\"Freight\") & \"＜ /TD ＞\" & _
\"＜ /TR ＞ \" _
)
objRS.MoveNext
Loop
Response.Write(\"＜ /TABLE ＞\")
End If
objRS.Close
objConn.Close
Set objRS = Nothing
Set objConn = Nothing
Response.Write(\"＜ /BODY ＞＜ /HTML ＞\")
% ＞
下面是测试结果：
我们来看一下各栏数字的含义：
0返回0个记录的页面所需要的TTLB（毫秒）。在所有的测试中，该值被视为生成页面本身（包括创建对象）的时间开销，不包含循环访问记录集数据的时间。
25以毫秒计的提取和显示25个记录的TTLB
tot time/25\"25\"栏的TTLB除以25，它是每个记录的总计平均时间开销。
disp time/25\"25\"栏的TTLB减去\"0\"栏的TTLB，然后除以25。该值反映了在循环记录集时显示单个记录所需时间。
250提取和显示250个记录的TTLB。
tot time/250\"250\"栏的TTLB除以25，该值代表单个记录的总计平均时间开销。
disp time/250\"250\"栏的TTLB减去\"0\"栏的TTLB，再除以250。该值反映了在循环记录集时显示单个记录所需时间。
上面的测试结果将用来同下一个测试结果比较。
四、是否应该通过包含引用ADOVBS.inc？
Microsoft提供的ADOVBS.inc包含了270行代码，这些代码定义了大多数的ADO属性常量。我们这个示例只从ADOVBS.inc引用了2个常量。因此本次测试（ADO__02.asp）中我们删除了包含文件引用，设置属性时直接使用相应的数值。
objRS.CursorType = 0?’ adOpenForwardOnly
objRS.LockType = 1’ adLockReadOnly
可以看到页面开销下降了23%。该值并不影响单个记录的提取和显示时间，因为这里的变化不会影响循环内的记录集操作。有多种方法可以解决ADOVBS.inc的引用问题。我们建议将ADOVBS.inc文件作为参考，设置时通过注释加以说明。请记住，正如第一部分所指出的，适度地运用注释对代码的效率影响极小。另外一种方法是将那些需要用到的常量从ADOVBS.inc文件拷贝到页面内。
还有一个解决该问题的好方法，这就是通过链接ADO类型库使得所有的ADO常量直接可用。把下面的代码加入Global.asa文件，即可直接访问所有的ADO常量：
＜ !--METADATA TYPE=\"typelib\"
FILE=\"C:Program FilesCommon FilesSYSTEMADOmsado15.dll\"
NAME=\"ADODB Type Library\" -- ＞
或者：
＜ !--METADATA TYPE=\"typelib\" UUID=\"00000205-0000-0010-8000-00AA006D2EA4\"
NAME=\"ADODB Type Library\" -- ＞
因此，我们的第一条规则为：
避免包含ADOVBS.inc文件，通过其他方法访问和使用ADO常量。
五、使用记录集时是否应该创建单独的连接对象？
要正确地回答这个问题，我们必须分析两种不同条件下的测试：第一，页面只有一个数据库事务；第二，页面有多个数据库事务。
在前例中，我们创建了一个单独的Connection对象并将它赋给Recordset的ActiveConnection属性。然而，如ADO__03.asp所示，我们也可以直接把连接串赋给ActiveConnection属性，在脚本中初始化和配置Connection对象这一额外的步骤可以省去。
objRS.ActiveConnection = Application(\"Conn\")
虽然Recordset对象仍旧要创建一个连接，但此时的创建是在高度优化的条件下进行的。因此，与上一次测试相比，页面开销又下降了23%，而且如预期的一样，单个记录的显示时间没有实质的变化。
因此，我们的第二个规则如下：
如果只使用一个记录集，直接把连接串赋给ActiveConnection属性。
接下来我们检查页面用到多个记录集时，上述规则是否仍旧有效。为测试这种情形，我们引入一个FOR循环将前例重复10次。在这个测试中，我们将研究三种变化：
第一，如ADO__04.asp所示，在每一个循环中建立和拆除Connection对象：
文章来源于领测软件测试网 https://www.ltesting.net/
