ado| objects in real life, programmers are inherently lazy. This fact makes us often mired in bugs. Especially when using ASP to process database connection, it will make you feel in the oil pan.
In ASP, we establish the database connection, and then use ADO to obtain the result of the data query; Adodb.connection and Adodb.recordset are the most commonly used. Let's look at a simple example to see how to use these two objects:
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
If you are not familiar with the database connection, please read this article first
(http://www.4guysfromrolla.com/webtech/faq/Databases/faq2.shtml).
We began to discuss our subject from objRS. What will we do when we finish objRS? Often programmers no longer do anything, they let the ASP to take care of the funeral. When the Server.CreateObject call occurs, the server allocates resources to manipulate new instances of these objects (instances), and if we do not explicitly notify the server that we are no longer using these allocated resources, the ASP should release those resources for us. Full trust in ASP is a bit risky. A safer and more believable approach is to explicitly close and clear our recordset and
An instance of the Connection object.
How do we close our objects and release the allocated memory? All we have to do is to call the following four lines of code when we have finished using both objects:
Objrs.close
Set objRS = Nothing
Objconn.close
Set objconn = Nothing
This will force the release of resources far better than relying on an ASP to implicitly automatically release. Now, you may be wondering: Is it really important that we do this? Who will write more than four lines of code in each ASP page with a database connection? The benefits of doing so far outweigh the burdens of writing more than four lines of code. Let's quote
Activeserverpages.com (http://www.activeserverpages.com/) The webmaster of some words:
"You should close the recordset, set it to nothing, turn off the connection, and set it in the same order as
Nothing. Standard resource fragmentation collection is incomplete and untrusted. [Previously mentioned fragment collection
Set, Charles refers to implicitly clearing the resources assigned by the server.]
"Datareturn[an ASP webhosting company] There are a number of sites that rely on IIS to automate fragmentation collection with terrible errors. After adding a few lines of code to Close/set nothing, the sites run as merrily as horses. All the stations have mandatory rules for the explicit release of resources. "
If Charles doesn't convince you, let's talk about a problem with no explicit use of memory redistribution, which is a real example. Brian Fairchild uses access to do a background database to support an ASP station. He found that every once in a while, the ASP page will completely stop the corresponding! HTML pages can be displayed normally, but all ASP pages are completely paralyzed and the system has to reboot. Finally, Brian discovers that the recordset and connection objects are explicitly closed and released, and the fault disappears. (Look at the article on the message board Brian talks about this failure) (http://www.aspmessageboard.com/forum/performance.asp?)
M=1321&P=1&F=23)
Charles Carroll also tells us a trick that users who use access should increase the default number of threads. Here's what Charles said:
"The default number of threads in registry access is 4. Adding it to 20 will make the server run unusually smooth, but it's especially useful for access, and our server's CPU usage is 100% from 8 o'clock in the morning to 5 o'clock, but after I've increased the number of threads, the CPU on the server is immediately cool. "
