ASP Performance Test Part II (EXT) (eight)

Should you use a local recordset?
ADO allows the use of a local (client) recordset, at which point the query extracts all the data in the recordset, and the connection can be closed immediately after the query completes, and the data is later accessed using a local cursor, which facilitates the release of the connection. Using a local Recordset is important for accessing remote Data services that require data to be used offline, so is it also helpful for ordinary applications?
Let's add the CursorLocation property and close the connection after the recordset is opened (client1.asp):
Set objRS = Server.CreateObject ("ADODB. Recordset ")
Objrs.cursorlocation = 2 ' adUseClient
objrs.activeconnection = Application ("Conn")
Objrs.locktype = 1 ' adlockreadonly
Objrs.open application ("SQL")
Objrs.activeconnection = Nothing
In theory, this approach is beneficial for the following two reasons: first, it avoids repeatedly requesting data through the connection while moving between records; second, it eases resource requirements because of the ease with which the connection can be released. However, the use of local recordsets from the table above appears to be less useful for improving efficiency. This may be because when you use a local recordset, the cursor always becomes a static type, regardless of what the program sets.
The 6th rule is as follows:
Unless you do require a recordset to be localized, you should avoid using the