A few things....
First, you don't need to append parameters. At least in SQL Server you do not. And, you definitely don't have to create the return_value parameter as you get that for free.
A performance tip that many espouse is that you should manually create your parameters. I don't believe this one at all. The time it takes to automatically get the parameters is so fast that if there was some incremental performance enhancement, nobody would notice.
In my opinion, what you are seeing is a bug with the OLE-DB Provider. i.e., if the parameter is already in place, the provider should not add the parameter again.
My advice, just stick with parameters getting refreshed automatically...
>I am currently facing a strange problem...
>
>Check out this code...
>
>
>
> oConnection = CreateObject("adodb.connection")
> with oConnection
> .Provider = "MSDAORA"
> .ConnectionString = "Persist Security Info=False;Password=quest;User ID=quest;Data Source=TJM"
> .Open
> endwith
>
> oCommand = CreateObject("adodb.command")
> with oCommand
> .ActiveConnection = oConnection
> .commandtext = "GetStatus"
> .CommandType = ADCMDSTOREDPROC
> .Parameters.append(.CreateParameter("RETURN_VALUE",3,4,0))
> .Parameters.append(.CreateParameter('p_mainkey',adVarchar,adParamInput,10,'0000000046'))
> .Parameters.append(.CreateParameter('p_module',adInteger,adParamInput,1,1))
> .Execute
> endwith
>
> ?oCommand.Parameters(0).Value
>
>>
>The strange part is that as soon as I execute this code I get to the lines..
>.CommandType = ADCMDSTOREDPROC
>
>As soon as I do this the parameters are appended to the command automatically after a split second delay. So after the parameter appends I have 6 parameters...
>
>This only happens on Oracle but not SQL Server. I don't mind it but I need
>it to work in a consistant way if possible...
>
>Anyone know how to disable this? I find it strange since the
>parameters.refresh doesn't work?!?!
>
>
>The other problem is oracle does not like the parameters with names like
>@p_mainkey is there a different syntax I can use on SQL Server because it SUCKS
>having to hardcode two methods for each server...
