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.