If you store connections in a session variable the benefits of connection pooling are abandoned. In this instance, the connection only serves the user for which the session was created and the connection is not released to the pool until the session's end.
Connection pooling parameters can be changed by altering registry settings. By default, connection pooling is turned on.
Because ASP pages serve as an umbrella for all components, test for errors in each component individually and then add it to the ASP page.
To confirm the syntax is correct, test your SQL statement directly from ISQL windows.
Use stored procedures wherever possible and test them from ISQL (that is, the Query Analyzer in SQL Server™ 7.0). Use ADO commands to call stored procedures.
Avoid using SQL text anywhere in the code.
Microsoft® Transaction Server (MTS) uses JIT (just-in-time) activation to instantiate components. It also destroys them when they call SetComplete. This can be a problem if your component calls SetComplete during a method call, and that method call is invoked in a loop from ASP, as was the case in ViewMyRequests.asp. The component was created and initialized with this script:
Set oUser = Server.CreateObject("CML.User")
oUser.DSN = Application("FmLib_ConnectionString")
nBorrowerNo = oUser.GetInfoFromTable(strLogon)
GetInfoFromTable also sets the internal value of BorrowerNo, to allow subsequent calls to ignore the value. Then requests were canceled using the following loop, however:
'--- Handle request cancellations here
If Request.QueryString("Action") = "Cancel" Then
Dim item
For Each item In Request.Form("Cancel")
Response.Write "DEBUG: Canceling " & item & "<br>"
oUser.CancelRequest item, nBorrowerNo
Next
End If
Notice that nBorrowerNo was passed here. It is an optional parameter, but because CancelRequest internally invokes SetComplete, the component is reconstructed by MTS for each invocation of the method. It doesn't seem to matter that the ASP declaratives include "<%@ Transaction=Required %>"
In summary, allow the caller to pass vital information as optional parameters to avoid having to reinitialize the component using a more expensive call like GetInfoFromTable.
In MTS 2.0 (which ships as part of the Microsoft Windows NT® 4.0 Option Pack), it is safe to use MTS.CreateInstance to instantiate any COM object, whether or not that object is transaction-aware. Calling this method does not cause MTS to produce an error nor does it produce extra overhead.
Using MTS to manage a non-transactional component simply means that the transactional attribute of the component is "does not support transaction," which is the default. There is no problem caused by registering such components with MTS. In reality, the Server.CreateObject method of ASP and the CreateInstance method of COM+ (MTS) are implemented such that they both call the CoCreateInstance function of COM.
Still, MTS handles object instantiation a bit differently than classic COM. In MTS, the ObjectContext.CreateInstance method attempts to create the object in the same context as the calling object, and possibly enlists it into an existing transaction, whereas this cannot be done with the CreateObject or New methods of Microsoft Visual Basic®.
Note In MTS 1.0, the MTS.CreateInstance call failed if the object being created was not an MTS object.
The Internet Information Server "$DATA" bug can be fixed by modifying the script map to append "::$DATA" to each file type appearing in the list. Because this can be a tedious task, Microsoft has released a hotfix (implemented as a Windows Scripting Host [WSH] script) to automatically modify the script map for you. The bug has been fixed in Windows NT® 4.0 Service Pack 4. More about the bug can be found at:
"::$DATA" Data Stream Name of a File May Return Source (KB Article Q188806)
http://support.microsoft.com/support/kb/articles/q188/8/06.asp
":$DATA" Data Stream Name Returns Source of a Remote File (KB Article Q193793)
http://support.microsoft.com/support/kb/articles/q193/7/93.asp