>Hi everybody,
>
>This would be more of a design question. We have a stored procedure with 27 parameters some of them having default values.
>
>In our VFP code there is a call for this SP inside a longer procedure with about 15 parameters.
>
>I am writing a C# code looking at the current VFP code (basically, I want to get the same functionality).
>
>I'd like to put that SP call into a separate method.
>
>I've created the method using that same parameters from VFP call (which omits about half of SP parameters) but now when I looked into an SP call I see it has more parameters.
>
>So, I'm thinking - would it make sense to rather create a class so I can pass an object to that new method instead? Having 27 parameters in a method looks unwisely and missing some parameters because they are not used in that particular call also doesn't look correct.
>
>What do you think the best approach here?
>
>Thanks in advance.

Even 15 params is a lot for a C# method (seem to recall MS recommend looking at alternatives over five). I'd favor wrapping the SP call in a method and probably passing in a custom class to hold the parameters. You could use an ExpandoObject but it's very easy to end up with runtime exceptions which must be caught - especially if the call is made from many places and simple classes are very lightweight objects.