Thanks, an interesting and powerful approach. This technique alone would not provide for the difference number of parameters but it could be coerced into the solution. I suppose that by storing the schema name in the web.config and then checking which schema is active the code could be bracketed to supply the correct parameters for either case. Or we could retain the old class until we are ready for production at which time we update the class and change the schema of the SP.
I have to "noodle" this one a little this technique can be very handy for a test server and live server configuration.

This is a good one.

Glenn



>Haha, you're going to try to make me remember a conversations from several months ago...
>
>How much do you know about schemas? I will start at the beginning just in case you don't know much about it.
>
>Basically, you can add another schema to your production database (let's call the schema "Development"). You can create a stored procedure with the same name, but different functionality, in this new schema. At this point, you would have two stored procs: dbo.usp_GetCustomerData and Development.usp_GetCustomerData. You would have the modifications be made to the Development.usp_GetCustomerData Stored Proc, and somehow in the security settings point to which one you want to use (this is where I am a little fuzzy).
>
>>Ok, you've piqued my interest. Please explain the theory to me.
>>
>>Glenn
>>
>>>Glenn,
>>>Sounds like you may be better served having another schema for your in-progress stored proc. I haven't done this personally, but have had it explained to me and it sounds like it would fit your situation.
>>>
>>>
>>>>The development team is "phasing" in a new stored procedure. It currently is being tested with a different name. In the class which calls this SP we need to check which version is being called so that we don't break a web application. The new SP will have two new parameters so the class which calls this SP can test the number of parameters. At some point the new one will replace the old one and we do not want to replace the other components.
>>>>
>>>>BTW this is the technique I cam up with to test the number of parameters thanks to the 4guys at Rolla.com
>>>>
>>>>
>>>>

>>>>Dim myCommand As New SqlCommand
>>>>myCommand.Connection = myConnection
>>>>myCommand.CommandText = stored procedure name
>>>>myCommand.CommandType = Data.CommandType.StoredProcedure
>>>>
>>>>myConnection.Open()
>>>>SqlCommandBuilder.DeriveParameters(myCommand)
>>>>myConnection.Close()
>>>>dim PCount as integer = myCommand.Parameters.count
>>>>

>>>>
>>>>
>>>>
>>>>>>Before calling a StoreProcedure is there any way to know how many parameters are required ?
>>>>>
>>>>>Isn't there an API? Or do the calls vary for some reason?