另一个 SqlParameterCollection 中已包含 SqlParameter

SqlParameter异常解析

最新推荐文章于 2022-05-25 22:02:07 发布

转载最新推荐文章于 2022-05-25 22:02:07 发布 · 64 阅读

0 ·

CC 4.0 BY-SA版权

原文链接：http://www.cnblogs.com/chenyongblog/p/3235718.html

本文解析了SqlParameter数组在同时供两个SqlCommand使用时出现另一个SqlParameterCollection中已包含SqlParameter异常的原因，并提供了解决方案，包括在每次使用后清除Command的Parameters集合。

出处：http://www.cnblogs.com/OldYongs/archive/2011/03/12/1982021.html#2742742

一般情况下，我们定义的一个SqlParameter参数数组，如：

SqlParameter[] parms = { new SqlParameter("@DateTime1", dtBegin), new SqlParameter("@DateTime2", dtEnd) };

如果只给一个SqlCommand使用，这种情况的参数使用，不会出现异常，但如果该参数数组同时给两个Sqlcommand使用，就会出现如下异常：

　　System.ArgumentException: 另一个SqlParameterCollection中已包含SqlParameter。

原因如下：声明的SqlParameter数组，而在循环的内部，每一次执行ExecuteNonQuery(或者其它命令方法)都由该方法内部的IDbCommand.Parameters.Add(IDbDataParameter)将SqlParameter数组添加到IDbCommand的IDataParameterCollection中。而framework机制限制两个IDataParameterCollection指向同一个对象。虽然ExecuteNonQuery方法内部声明了一个IDbCommand的临时对象，理论上讲，这个包含了IDataParameterCollection的IDbCommand对象会在ExecuteNonQuery方法结束时从内存中释放。但是实际上可能是由于垃圾回收机制并没有将IDbCommand临时对象即时的回收，而且改对象绑定的Parameter集合也存在，就像一个DropDownList添加Item一样。这样在下一个循环执行的时候，会导致两个IDataParameterCollection指向同一个对象，此时出现问题。解决方案一：在每一次循环时，重新生成对象，但这样会产生大量的垃圾变量，不可取。解决方案二：将使用完之后的Command命令的Parameters集合清空。推荐使用，类似代码如下：

 public static int ExecuteNonQuery(string sql, CommandType cmdType, params SqlParameter[] pms)
        {
            using (SqlConnection con = new SqlConnection(conStr))
            {
                using (SqlCommand cmd = new SqlCommand(sql, con))
                {
                    cmd.CommandType = cmdType;
                    if (pms != null)
                    {
                        cmd.Parameters.AddRange(pms);
                    }
                    con.Open();
                    int r = cmd.ExecuteNonQuery();
                    cmd.Parameters.Clear();
                    return r;
                }
            }
        }

另外，如果不是数组，只是一个SqlParameter变量，如：

SqlParameter parm = new SqlParameter("@Cust_Id", CustId.Trim());;

转载于:https://www.cnblogs.com/chenyongblog/p/3235718.html