John,

This is a bit strange. From what you posted, it sounds like you couldn't get ExecuteNonQuery to work when you had a Return in your Stored Proc unless you added the extra parameter. Is this correct? We have many Stored Procs that return values (and we mostly don't care about the return values, so we never check them). The ExecuteNonQuery works just fine without the additional parameter. I wonder why you had a problem with that?

~~Bonnie




>It does use output parameters - that was my question, but the way ExecuteNonQery works with SQL Server, the fact that my proc also returned a return value means that you have to add a dummy "parameter" in the Parameters collection that handles the return value. I know it's bizarre, and I never would have guessed it, but I found the reference to it in Francesco Balena's book "Programming Visual Basic.NET" p. 1034, where he says, "If the stored procedure returns a value, you must define an aditional parameter: the name of the parameter doesn't matter as long as it's the first parameter appended to the Parameters collection and its Direction property is set to ReturnValue."
>
>I was able to confirm this by experimenting with the SqlCommandBuilder.DeriveParameters() method. When I used it for debugging purposes, it "derived" the phony return value "parameter".
>
>After a little experimentation, I was able to confirm that SqlCommand.ExecuteNonQuery works fine, once I either:
>1. Omitted the Return call from my stored procedure, or
>2. Added the extra parameter to my parameters collection.
>
>This really has nothing to do with MM - it's purely a matter of discovering the idiosyncrasy of SqlCommand.ExecuteNonQuery (which I could not find anywhere in the Microsoft documentation - certainly not in the documentation for ExecuteNonQuery.)
>
>MM just wraps the SqlCommand.ExecuteNonQuery as *.ExecNonQuery in the MM derived classes.
>
>Thanks for your help - it did eventually get me to the answer I needed.