What is the best choice for improving ASP Performance (cont.)

In the first part of this article, I reviewed some basic questions about ASP development, and introduced some of the results of performance testing to understand how the code we put on the page might affect performance. In the second part of this series, we will explore the broadest use of proven ASP, which is to use database content interactively through ActiveX Data Objects (ADO). ADO is a common and simple database interface for Microsoft.
ADO has many functional settings, so the biggest challenge in preparing this article is to limit the scope of the test problem. Considering that reading large data sets imposes a heavy load on the Web server, I decided to confine my research to the aspect of finding the most optimized configuration for using an ADO recordset. However, this limitation raises a challenge because ADO provides a variety of ways to perform the same function. For example, a recordset can be recovered from the recordset class, or it can be recovered from the connection and command classes. In addition, once you have a recordset, there are a number of options that dramatically affect performance. Therefore, as in the first part, I will address as many specific issues as possible.
Objective
The purpose of my research is to get enough information to find the answers to the following questions:
* Should you use adovbs.inc include files?
* Should you create a separate connection object when using a recordset?
* What is the best way to restore a recordset?
* Which of the types of pointers and locks are most effective?
* Should you use a disconnected recordset?
* What is the best way to set Recordset (Recordset) properties?
* What is the most efficient way to reference a field value in a recordset?
* Can you use temporary strings to better replace buffers?
How is the test set up?
For testing in this study, we have assembled 21 ASP pages (included in this download). Each page is configured to return a recordset run with 3 different queries, with 0, 25, and 250 records in each set. This helps us isolate the problem of loading the recordset and the performance issues on the cycle of the recordset.
To meet these changing conditions, both the database connection string and the test SQL string are stored as application variables in the Global.asa. Because our test database runs on Microsoft SQL Server 7.0, our connection string specifies that OLE DB is the current database as the connection provider, the Northwind sample database (included in the SQL server). The SQL SELECT statement requires 7 specific domains in the Northwind Orders table.
< SCRIPT language=vbscript Runat=server >
Sub Application_OnStart
Application ("Conn") = "Provider=sqloledb;" & _
"Server=myserver;" & _
"UID=SA;" & _