(Author: Green Apple studio compilation, 2000 at 13:45 on November 13)
In the first part of this article, I review some basic issues related to ASP development, introduced some of the results of performance testing to understand what the code we placed on the page may affect the operation performance. In this series of second part, we will explore the most extensive use of the armed ASP, namely, using the database content through the ActiveX Data Object (ADO). ADO is a Microsoft universal and simple database interface. ADO has a lot of functional settings, so the biggest challenge when preparing this article is to limit the scope of the test problem. Considering that reading a big load is applied to the web server, I decided to limit the contents of the study to find the optimized configuration for using the ADO record set. But this restriction has put forward a challenge because ADO provides a variety of ways to perform the same function. For example, the record set can be recovered from the Recordset class or recover from the Connection and Command classes. In addition, once you have a recordset, there are many options that will dramatically affect performance. Therefore, like the first part, I will involve some specific problems as much as possible. The purpose of my research is to get enough information to find the answer to the following question: * Will you use Adovbs.inc containing files? * When using a recordset, should you create a separate Connection object? * Restore a record set What is a good way? * In the type of pointer and lock, which is the most effective? * Do you should use a disconnected record set? * What is the best way to set the record set (RECORDSET) property? * Reference Record Central Domain What is the most effective way to value? * Can I use a temporary string to replace the buffer? How is the test set up? For testing in this study, we share 21 ASP pages (included in this article download content). Each page is configured to return to record sets with 3 different queries, which are 0, 25, 250 records in these records. This helps us isolate the problem of loading records and performance issues on record concentration cycles. To meet these changes, database connection strings and test SQL strings are stored as application variables in Global.asa. Because our test database is running on Microsoft SQL Server 7.0, our connection string specifies OLEDB as a connection vendor, the Northwind sample database (included in the SQL server) as the current database. The SQL SELECT statement requires 7 specific domains in the Northwind ORDERS table.
