The following code is the LookupBarcode method of the Admin object:
'--- Lookup barcode and return bib#
Public Function LookupBarcode(ByVal Barcode As String) As ADODB.Recordset
Dim rs As ADODB.Recordset
Dim strSQL As String
'--- Check that we have valid parameters
If IsEmpty(Barcode) Or Barcode = "" Then
Err.Raise N_INVALIDBARCODE, "Admin.CheckOut", S_INVALIDBARCODE
End If
On Error GoTo ErrHandler
strSQL = "SELECT t.bib# as BibNo,t.Title,t.Call,t.Coll" & _
" FROM Title AS t JOIN Item AS i ON t.bib#=i.bib#" & _
" WHERE i.barcode='" & Barcode & "'"
Set rs = MTS.CreateInstance("ADODB.Recordset")
rs.Open strSQL, ConnectionString
Set LookupBarcode = rs
Exit Function
ErrHandler:
Err.Raise Err.Number, Err.Source, Err.Description
End Function
We're involving MTS because we're creating a recordset.
Near the top of this code the Admin object checks parameters, composes an SQL query statement, and then uses the MTS object to create a new instance of the ADODB Recordset object. This statement creates the Recordset object:
Set rs = MTS.CreateInstance("ADODB.Recordset")
Note If we had simply used the New keyword or CreateObject method to instantiate the Recordset object, Visual Basic would have invoked the COM surrogate process to create the object, sidestepping MTS altogether.
This new Recordset object runs in the context of the MTS object, which is the same context that the Admin object runs in. And the Admin object runs in the MTS object context because of its entry in the system registry. Installing the CML application also installs a new MTS package (see Installing the CML MTS Package) that includes the CMLAdmin object. This creates a registry key for the CMLAdmin object, and points its classID to the MTxAS (MTS) DLL, not CML.DLL itself.
The results of this installation are as follows: An ASP file of the CML application (Checkout.asp, for example) needs to use an Admin object and uses the following line to create it:
Set oAdmin = Server.CreateObject ("CML.Admin")
Because this new CML Admin object is to be managed by MTS, COM finds in the registry (and invokes) not the Admin object itself but MTS. Because the MTS entry contains a class ID to instantiate the Admin object, the MTS surrogate uses the class ID that it was passed to find the CML DLL in the registry, and instantiates it.
Once the CML Admin object is running in the MTS context, any objects it contains will also run in the MTS context. MTS has control over these objects because they are now running in its context.
You cannot directly instantiate private objects (such as the CML TableQueue object) within the context of MTS. Private objects are not registered, and therefore would not be recognized as valid COM components. However, the private object can be aware, through the object that invoked it, of an overall MTS object context. In the case of the CML, this means that the User object or the Admin object, after creating an MTS object context, can then create a TableQueue object (using New) that will be controlled by MTS.