Sql Server数据库中游标+事务的存储过程

　　前两天跟.net前辈请教数据库游标的问题，据说游标现在很少用了，在项目中遇到了循环更新的问题，相比循环调用存储过程(反复连接、断开数据库)而言，把逻辑写在存储过程中会更高效些，在这里想做个简单的例子和大家分享一下：

C#代码部分：创建一个datatable，作为参数传入存储过程

            DataTable dt = new DataTable();
            dt.Columns.Add(new DataColumn("id", typeof(int)));
            dt.Columns.Add(new DataColumn("name", typeof(string)));

            object[] obj = new object[] { 1, "aaa"};
            dt.Rows.Add(obj);
            obj = new object[] { 2, "bbb"};
            dt.Rows.Add(obj);

            using (SqlConnection con = new SqlConnection(server=.;uid=sa;pwd=;database=Database;))
            {
                    con.Open();
                    SqlCommand com = new SqlCommand("ProcName", con);
                    com.CommandType = CommandType.StoredProcedure;
                    com.Parameters.AddWithValue("@GuidTable", dt);
int i = com.ExecuteNonQuery();
                    if (i <= 0)
                    {
                        Response.Write("修改失败");
                    }
                    else
                    {
                        Response.Write("修改成功"+i+"条数据");
                    }
              }

 

数据库存储过程部分：创建一个table类型，从传入的datatable中读取值赋给变量，依次循环

CREATE TYPE TypeName as TABLE  --创建一个表格的类型
(
 Id int not null,
 Name varchar(50) not null
)

CREATE PROCEDURE [dbo].[ProcName]  --创建存储过程
( 
 @GuidTable CELLDEF READONLY
 ) AS
 declare @ID int
 declare @NAME varchar(50)

SET XACT_ABORT ON 
BEGIN TRANSACTION  --开始事务
declare cur cursor  --定义一个游标 
read_only for
SELECT Id,Name FROM @GuidTable  --为所获得的数据集指定游标
open cur  --打开游标
fetch next from cur into @ID,@NAME  --把提取操作的列数据放到局部变量中
while(@@fetch_status=0)  --返回被 FETCH 语句执行的最后游标的状态,其值有以下三种:0 FETCH 语句成功,-1 FETCH 语句失败或此行不在结果集中,-2 被提取的行不存在

begin
 update TableName set NAME=@NAME where ID=@ID;

if @@error>0  --执行错误回滚
  begin 
    rollback tran 
    return
  end

fetch next from cur into @ID,@NAME  --游标移至下一行，给变量值赋

end
close cur  --关闭游标
deallocate cur  --删除游标  
COMMIT TRANSACTION  --提交事务

 

 

 

 

 

　　

转载于:https://www.cnblogs.com/Jackie-sky/archive/2012/06/18/2553128.html