OK, I ran a test with the following stored procedure:

CREATE PROCEDURE test
@text text
AS
SELECT 'hello world'

And the following VB code using ADO 2.6:

    Dim oCmd As ADODB.Command
    Dim oConn As ADODB.Connection
    Dim oRs As ADODB.Recordset
    Dim oParam As ADODB.Parameter
    
    Set oConn = New ADODB.Connection
    oConn.ConnectionString = "Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=pubs;Data Source=(local)"
    oConn.Open
    
    Set oCmd = New ADODB.Command
    With oCmd
        .ActiveConnection = oConn
        .CommandText = "test"
        .CommandType = adCmdStoredProc
        .Parameters.Refresh
    End With
    
    For Each oParam In oCmd.Parameters
        Debug.Print oParam.Type
    Next
    
    Set oParam = Nothing
    Set oCmd = Nothing
    oConn.Close
    Set oConn = Nothing

The debug windows contained:
3 (adInteger) for the return value of the proc
200 (adVarChar) for the Text parameter

BTW, changing the parameter datatype from TEXT to NTEXT returned a adVarWChar enum.

At this point, I'd like to throws in my opinion: I, and others, don't believe in allowing ADO to automatically determine the parameter information. While it is a convience to the developer, it causes an extra round trip to the server.

Just for kicks, I ran the code above while the SQL Profiler was running to determine what was happening within SQL Server. ADO (or SQLOLEDB more likely) calls a proc called sp_procedure_params_rowset, requiring 34 page reads and 10ms on my computer. While I wouldn't consider this a very complete test, it does show that SQL Server does have to do some work to retrieve the parameter information.

Just food for thought.

-Mike