Handling Arrays Between ASP and COM

Realizing all shops and projects are different, I don抰 believe that I have made a database call from within ASP since summer ?998, so understand that I am coming from a component-driven Web perspective. Furthermore, I can抰 remember the last time a client has asked me to create a static HTML page. The majority of what we do is dynamic. Sometimes, I find myself calling 411 and asking for Number where Last Name = 慡mith?and First Name like 慗o%?

One strategy for improving the structure of our Web development involves the way we pass data between ASP and components. I will usually try to group items (such as rights) together with the user they apply to and pass them in a variant array between components and/or back to ASP. In this way I can pass data from record sets (using the getRows method of ADODB.Recordset) and database updates to COM as well as my grouped rights all in the same type (structure) of variable. This is a question of 揺ase of use.? You may prefer to return record sets to ASP as themselves. My rationale is that I will definitely use arrays to pass and manipulate data within ASP and VB, so I抎 rather pass my record sets that way as well. Chalk it up to personal preference.

To quickly build components and save myself from breaking interfaces^*, I like to use arrays to pass data back and forth between components. At times I also use this technique to pass data from ASP to COM. Below are two code snippets. Looking at Snippet 1, I am constructing a simple two-dimensional array (in this case it didn抰 need to be two-dimensional).

Snippet 1: Create an ASP called testCase.asp, and run it.

<% @Language="VBScript" %>
<% Option Explicit %>
<%
Dim tcs
Dim rc
Dim vntInput(0,4)
Dim i

vntInput(0,0) = Request.QueryString("strUser")
vntInput(0,1) = Request.QueryString("intCreate")
vntInput(0,2) = Request.QueryString("intDelete")
vntInput(0,3) = Request.QueryString("intModify")
vntInput(0,4) = Request.QueryString("intView")

If Len(vntInput(0,0)) = 0 Then
	Response.Redirect("testCase.asp?strUser=myDomain/arichman&intCreate=1&intDelete=1&intModify=0&intView=1")
End If

vntInputString = "String Input Value"

' First make sure we have a valid array
For i = 0 to UBound(vntInput,2)
	Response.write "Loop Count " & i & " " & vntInput(0,i) & "<BR>"
Next
Response.Write "<HR>"


Set tcs = Server.CreateObject("TestCases.ArrayFailure")
     rc = tcs.AcceptArray(vntInput)


' Now see what we have left
For i = 0 to UBound(vntInput,2)
	Response.write "Loop Count " & i & " " & vntInput(0,i) & "<BR>"
Next

%>

Create an ActiveX component called TestCases.dll and a class called ArrayFailure.

Snippet 2:

Public Function AcceptArray(ByVal vntArray As Variant) as Integer

    DoEvents

End Function

Add this snippet to the above ASP sample in place of the ASP-built array.

Snippet 3

<% @Language="VBScript" %>
<% Option Explicit %>
<%
Dim tcs
Dim rc
Dim vntInput
Dim vntInputString
Dim i

dim cta 

set cta = Server.CreateObject("TestCases.ArrayFailure")
rc = cta.ConvertToArray("a,b,c,d,e,f,g,h,i,j,k,l", ",", 3, vntInput)

Note: You will not need to dimension the bounds of this array (see above code appearing in bold) in ASP. VB will do that inside your ConvertToArray function.

Create an ActiveX component and class to house useful utilities.

Snippet 4:

 
Option Explicit
Private Const vectorSize As Integer = 10

Public Function ConvertToArray(ByVal strParse As String, _
                                          ByVal strDelimiter As String, _
                                          ByVal intDimensions As Integer, _
                                          ByRef vntArray As Variant) As Integer
                                          
    Dim intColumns As Integer, intCnt As Integer, intPos As Integer
    Dim i As Integer, j As Integer, n As Integer
    Dim vntTemp As Variant
    Dim strTemp As String, chrTemp As String
    
    ' loop for number of instances of the delimiter and store it in an array for later use.
    ReDim vntTemp(vectorSize)
    n = 0
    For intPos = 1 To Len(strParse)
        chrTemp = Mid$(strParse, intPos, 1)
        If Mid$(strParse, intPos, 1) = strDelimiter Then
            intCnt = intCnt + 1
            FillAndSize n, strTemp, vntTemp
            strTemp = ""
            n = n + 1
        Else
            strTemp = strTemp & chrTemp
        End If
    Next
    FillAndSize n, strTemp, vntTemp
    ReDim Preserve vntTemp(n)
    
    ' redim the array (deprecating by 1 for base zero array) by row and column
    intColumns = (intCnt + 1) / intDimensions
    intDimensions = intDimensions - 1
    intColumns = intColumns - 1
    ReDim vntArray(intDimensions, intColumns)
    
    ' populate the newly redimensioned array
    n = 0
    For j = 0 To intColumns
        For i = 0 To intDimensions
            vntArray(i, j) = vntTemp(n)
            n = n + 1
        Next
    Next
                       
End Function

Private Sub FillAndSize(ByVal intCount As Integer, ByVal strTemp As String, ByRef vntInput As Variant)
    
    Dim i As Integer
    i = intCount Mod vectorSize
    If i = 0 And intCount >= vectorSize Then
        ReDim Preserve vntInput(intCount + vectorSize)
    End If
    vntInput(intCount) = strTemp

End Sub

The main point is that you have your data in an array that will work for your needs in both ASP and VB. There are a couple of things to remember when you are creating this sort of array builder. If you are going to use a .getRows method for data retrieval in COM, you will notice that it populates arrays by indexing on the outer element. Also remember that if you plan on resizing arrays in VB sent in as a parameter by ASP, you will need to ReDim Preserve the array. VB will only allow you to resize the outer element of your array (e.g., vntArray(1,10) can only be resized by (1,n). The 1 in this example is fixed).

Public Function Modify(ByVal lngItemNum As Long, _
                              ByVal strTableName As String, _
                              ByVal vntModifications As Variant) As Integer
                              
    Dim intCols As Integer, intRecs As Integer
    Dim strUpdate As String, strQuery As String
    Dim cn As ADODB.Connection
    Dim rs As ADODB.Recordset
    
    ' for each modification add a new name/value pair to the update statement
    For intCols = 0 To UBound(vntModifications, 2)
        strUpdate = "," & strUpdate & vntmods(0, intCols) & "=" & vntmods(1, intCols)
    Next
    ' trim off the leading comma in the update string
    strUpdate = Mid$(strUpdate, 2)
    strQuery = "UPDATE " & strTableName _
                & " SET " & strUpdate _
                & " WHERE Item_Num = " & lngItemNum
    
    Set cn = CreateObject("ADODB.Connection")
    cn.Open "OLEDB PROVIDER CONNECTION STRING"
    rs = cn.Execute(strUpdate, intRecs)
    
End Function

Keeping in mind generic nature of the example, if the case demanded that I need more criteria (the where statement in this snippet) to make my update, I would need to define that in the design stage and include that in my parameter list. For the sake of simplicity, consider the above example to be updating a table with a unique index Item_Num. We could construct myriad different arrays containing a name/value pair with which we wish to update the record. Of course, we could use a string for input. We could continue to grow the string and never break the interface as well. If we know that the input will never need massaging, this will work fine. On the other hand, if we may need to massage data, it is far simpler to test elements of an array than parse a string (see Snippet 6). This is an example of the ease of testing a condition in an array vs. parsing a string. Snippet 6

 
. . .
' for each modification add a new name/value pair to the update statement
    For intCols = 0 To UBound(vntModifications, 2)
        If UCase(CStr(vntmods(0, intCols))) = "FIRST_NM" Or UCase(CStr(vntmods(0, intCols))) = "LAST_NM" Then
            strUpdate = "," & strUpdate & vntmods(0, intCols) & "=" & UCase(CStr(vntmods(1, intCols)))
        Else
            strUpdate = "," & strUpdate & vntmods(0, intCols) & "=" & vntmods(1, intCols)
        End If
    Next
. . .

^** Declare all function parameters explicitly ByVal ("A way of passing the value, rather than the address, of an argument to a procedure. This allows the procedure to access a copy of the variable. As a result, the variable's actual value can't be changed by the procedure to which it is passed." MSDN Visual Studio 6.0) except those intended to return a value ByRef. This will prevent changing the values of data that may be used later in code, be that ASP or other components.

^*** Always compile components using binary compatibility (see Design Note below). This will enable others calling these objects to declare their components using vTable Binding (Early Binding) and to not need to recompile every time internal code is changed. According to MSDN; "For in-process components, vtable binding reduces call overhead to a tiny fraction of that required for DispID binding." VB generates a GUID for components in the Windows Registry. When you compile with binary compatibility, VB will use the previous GUID for its registry entry, provided the interface has not changed. Consequently, customers will never need to recompile their objects when we recompile our component., (This is only pertinent to "component-to-component" design. This will have no effect on ASP because all ASP is late bound.) Although it would be very convenient to create one giant ActiveX component with all of your classes, I wouldn抰 advise it. By doing this you greatly increase the number of times you will have to change interfaces, thus breaking binary compatibility. Creating this large ActiveX component is fine if you are creating specific classes that will not be shared business objects ?others aren抰 relying on your GUID. I try to group my classes in their functionality (relationships), but any type of grouping will work. Note: Be mindful of cross dependencies that can make build time a nightmare.

^** Declare all function parameters explicitly ByVal ("A way of passing the value, rather than the address, of an argument to a procedure. This allows the procedure to access a copy of the variable. As a result, the variable's actual value can't be changed by the procedure to which it is passed." MSDN Visual Studio 6.0) except those intended to return a value ByRef. This will prevent changing the values of data that may be used later in code, be that ASP or other components.

^*** Always compile components using binary compatibility (see Design Note below). This will enable others calling these objects to declare their components using vTable Binding (Early Binding) and to not need to recompile every time internal code is changed. According to MSDN; "For in-process components, vtable binding reduces call overhead to a tiny fraction of that required for DispID binding." VB generates a GUID for components in the Windows Registry. When you compile with binary compatibility, VB will use the previous GUID for its registry entry, provided the interface has not changed. Consequently, customers will never need to recompile their objects when we recompile our component., (This is only pertinent to "component-to-component" design. This will have no effect on ASP because all ASP is late bound.) Although it would be very convenient to create one giant ActiveX component with all of your classes, I wouldn抰 advise it. By doing this you greatly increase the number of times you will have to change interfaces, thus breaking binary compatibility. Creating this large ActiveX component is fine if you are creating specific classes that will not be shared business objects ?others aren抰 relying on your GUID. I try to group my classes in their functionality (relationships), but any type of grouping will work. Note: Be mindful of cross dependencies that can make build time a nightmare.

http://15seconds.com/files/990826.zip