Asp – In Classic asp, can I store a database connection in the Session object

Yes, only in memory

From MSDN Full Article

ASP Implementation

The native ASP session can only store session data in memory. In order to store the session data to SQL Server, a custom Microsoft® Visual Basic® 6.0 COM object is written to manage the session state instead of using the native session object. This COM object will be instantiated in the beginning of each Web request and reload the session data from SQL Server. When the ASP script is finished, this object will be terminated and the session state will be persisted back to SQL Server.

The primary purpose of the Visual Basic 6 COM Session object is to provide access to the Microsoft® Internet Information Server intrinsic objects. The Visual Basic 6.0 COM Session object uses the mySession class of SessionUtility assembly to hold the session state, and the SessionPersistence class of SessionUtility to load and save session data with SQL Server. The mySession and SessionPersistence classes are exposed as COM objects using the regasm.exe utility. The regasm.exe utility can register and create a type library for the COM client to consume Framework classes.

The session state information is reloaded during the construction of the object. The constructor (class_initialize) will first retrieve the session cookie, session timeout (SessionTimeOut), and database connection string (SessionDSN) from the Application object, and create an instance of the class mySession to hold the session data. Then the constructor will try to reload the session data from SQL Server with the given cookie. If the SQL Server does not have the session information, or the session has been expired, a new cookie will be issued. If the SQL Sever does return with the session state data, the session state will be stored in the mySession object.

I can't explain why your code doesn't work looks fine to me.

The object is created in a script context which is subsequently torn down after the request is complete. Hence whilst the type name is available the object's function is broken.

I can tell you its not a good idea to store objects in the Session even those not created in script.

Most objects used in ASP exist in a single thread. Once created only the thread that created the object may access the object. To cope with this once you have stored an object in the session ASP affiliates the session with the specific worker thread that created it the object.

When a subsequent request for that session arrives it must now be handled by its specific worker thread. If that thread happens to be busy working for some other request the sessions request is queued, even if there a plenty of other available worker threads.

The overall effect is to damaging the applications scalability where the work load can become unevenly distributed across the worker threads.