Rex,

Creating your SqlCommands in global.asax is an interesting idea. But it's not the most efficient solution unless all of the web forms in the project use the SqlCommand. You can accomplish the same effect by storing the SqlCommand object in the session cache. To do this, expose the SqlCommand object as a Public Property in the Class block of your startup form and instantiate the object in the Page.Load method. Then use the session cache as the backing. E.g.:

Public Class MyForm
Inherits System.Web.UI.Page

    Public Property MyCommand() As SqlCommand
        Get
            Return Session("MyCommand")
        End Get
        Set(ByVal Value As SqlCommand)
            Session("MyCommand") = Value
        End Set
    End Property

    Private Sub Page_Load(ByVal sender As System.Object, _
        ByVal e As System.EventArgs) Handles MyBase.Load


        If Not Page.IsPostBack
            Dim i As Integer

            MyCommand = New SqlCommand(myQuery, myConnection)
            Dim CommandParameters() As SqlParameter = _
                SqlHelperParameterCache.GetSpParameterSet( _
                MyCommand.Connection.ConnectionString, CommandProcedureName)
            For i = 0 To CommandParameters.Length - 1
                _Command.Parameters.Add(CommandParameters(i))
            Next
        End If
    End Sub

End Class

If you want to use the SqlCommand in other pages, you can use the same Public Property declaration, or you can reference the MyForm class and access the original object:

Protected WithEvents MyFormRef as MyForm
.
.
MyFormRef.MyCommand.ExecuteReader()

Another reason why you would want to declare the SqlCommand in a Page instead of in the global.asax is that you may want to subclass a Web Form template that you have created with the SqlCommand down the road.

Happy coding!

>Keith,
>
>Thanks for the response
>
>Would I be better off caching the parameters in advance, in the Application_Start method in the Global.ASAX file?
>
>Thanks again
>
>Rex
>
>>The advantage is that you don't have to hand-code a bunch of SqlCommand.Parameters.Add() statements. The other available method of setting up the SqlCommand parameters is to use the SqlCommandBuilder, which has a larger footprint than the Blocks and retreives the parameter metadata from SQL Server each time it is used.
>>
>>P.S. The parameters collection is instanced each time a SqlCommand object is created, but not when the stored procedure is used.
>>
>>>All,
>>>
>>>In the Microsoft Data Access Application Block I noticed that parameter caching was used. What are the advantages of data caching instead of instantiating the parameter objects each time a stored procedure is used?
>>>
>>>Thanks
>>>
>>>Rex