今天遇到个情况,在数据库客户端上单独执行(或调试模式)存储过程,都不会抛出异常信息。
但是通过C#程序,调用数据接口,数据接口是使用 SqlSugar 在C#中创建了一个事务(嵌套1个存储过程),如果存储过程内部出错,触发了存储过程自身的ROLLBACK,程序端就会接受到抛出的异常信息:EXECUTE 后的事务计数指示 BEGIN 和 COMMIT 语句的数目不匹配。上一计数 = 1,当前计数 = 0
经过资料查询和研究,找到一位博友的阐述如下:
因为存储过程的ROLLBACK命令清空了@@TRANCOUNT,该全局变量存储了当前连接中的事务数量,每当执行BEGIN TRAN命令时,该变量加1,每当执行COMMIT TRAN命令时,该变量减1,每当执行ROLLBACK TRAN命令或者ROLLBACK TRAN POINT_NAME时(没有保存点时),该变量清空。如果执行ROLLBACK TRAN POINT_NAME且有保存点POINT_NAME时,@@TRANCOUNT不变,但保存点POINT_NAME失效,再次ROLLBACK TRAN POINT_NAME时依旧是清空@@TRANCOUNT。
上面那段很饶,但全是干货,可以细细咀嚼。
而c#事务嵌入存储过程事务进行执行之后,因为触发了存储过程内部的ROLLBACK TRAN,所以@@TRANCOUNT清空为0,导致c#代码创建的事务再进行下一步操作时找不到对应的事务了,所以就报出了上面的异常。(具体里面的机制,有兴趣的可以深入研究一下)
面对这种问题,有一种解决方案,那就是在创建存储过程时,尽量在执行存储过程的事务之前先判断一下自身是否被嵌入在另外一个事务之内。如果未被嵌入在另外一个事务之内,则使用BEGIN TRAN POINT_NAME来开启一个事务。如果被嵌入在另外一个事务之内,则使用SAVE TRAN POINT_NAME来创建一个保存点。无论是开启事务还是设置保存点,其回滚都可以写为:ROLLBACK TRAN POINT_NAME,执行该回滚命令的区别就是,当为保存点模式时,@@TRANCOUNT不变,不会对存储过程自身的上级事务产生影响。当为开启事务模式时,也就意味着自身上级并没有事务,那么清空@@TRANCOUNT自然也就无所谓了。
--结构示例 --开启事务之前先获取当前的事务数量@@TRANCOUNT DECLARE @T_COUNT INT SET @T_COUNT = @@TRANCOUNT IF(@T_COUNT > 0)--有上层事务 SAVE TRAN POINT_NAME--创建保存点 ELSE--无上层事务 BEGIN TRAN POINT_NAME--开启新事务 --处理过程 --如果无异常 IF(@T_COUNT > 0)--有上层事务 --不作任何提交处理,提交处理交由上层事务 ELSE--无上层事务 COMMIT TRAN POINT_NAME--直接提交 --如果有异常 ROLLBACK TRAN POINT_NAME--执行回滚,如果有保存点,则意味着存在上层事务,则回滚到保存点,@@TRANCOUNT清空。如果无保存点,则说明无上层事务,则将事务全部回滚,并将@@TRANCOUNT清空为0
分析上面这段内容后发现,大致逻辑是对的,其中有一句我认为作者的理解有误:” 导致c#代码创建的事务再进行下一步操作时找不到对应的事务了,所以就报出了上面的异常。"
经过本人实践得出结论,其实报计数点不匹配错误的是 存储过程内部ROLLBACK触发的,原因是存储过程回滚的机制是 只能回滚自身体系事务内的第一个事务点(即存储过程中的第一个BEGIN TRAN), 存储过程内的@@TRANCOUNT 计数是包含 程序内的BEGIN TRAN,但无法对程序内的 BEGIN TRAN 进行回滚,所以导致的 计数点不匹配报错。
为了证实这个观点,又做了一个父存储过程嵌套子存储过程,(假设 把父存储过程看成原来的C#程序,子存储过程看成原来的 C#程序调用的存储过程),测试子存储过程内回滚的测试,直接回滚到 父存储过程的第一个 BEGIN TRAN,顺利ROLLBACK且无报错信息。
由此可见以上个人的理论推断应该是正确的。
结论: 程序代码内有事务且嵌套存储过程的,存储过程内部的ROLLBACK无法回滚到程序代码内事务的计数点,所以报计数点不匹配的错误。
解决方案:
存储过程内,BEGIN TRAN之前,判断下@@TRANCOUNT
@@TRANCOUNT > 0 (有上层事务), 使用 SAVE TRAN POINT_NAME (保存点) 模式
@@TRANCOUNT <= 0 (无上层事务), 使用 BEGIN TRAN (开启新事务)模式
欢迎各位发表不同意见,一同探讨技术问题!