㈠ sql语句如何rollback
rollback是针对事务的，你如果没有在执行语句之前开启事务，那么无法rollback，建议你还是想别的办法吧，事务语句如下（sqlserver的给你借鉴）：
--开启事务
begin tran
--执行操作
update Accounts_UsersExp set TelPhone=123456 where userid=14
--执行错误事务回滚
rollback
--如果正确进行事务提交
commit
可以勾选一句执行一句，但是commit了就不能rollback
㈡ SQL语言中,用于事务回滚的语句是什么
回滚要放在事务里面进行，才能进行回滚；sql里面的事务使用关键字TransAction
1：可以用try catch捕获
begin try
begin tran
update table set a=1；
commit tran
end Try
begin catch
rollback tran
end catch
2：可以使用error 全局变量
begin tran
update tablename set ad=1111
if @@error<>0 begin rollback end
commit tran
注意：如果一个事务写了 begin trans ,后面一定要跟上 commit tran或 rollback transaction ，否则可能导致被锁
㈢ sql中的存储过程里怎么写事务回滚啊
CREATE PROC [dbo].[notice_Delete] --- 同时删除该通知书和对应的节点
@tbl VARCHAR(30),
@pid INT
AS
BEGIN
DECLARE @tblname VARCHAR(30) ;
DECLARE @sql VARCHAR(1000) ;
SET @tblname = @tbl
SET @sql = 'delete ' + @tblname + ' where id ='
+ CONVERT(VARCHAR(10), @pid)
BEGIN TRAN --开始事务
EXEC ( @sql
)
IF ( @@rowcount = 0 ) --执行结果影响行数为0
BEGIN
ROLLBACK TRAN --回滚
END
ELSE
BEGIN
DELETE FROM tbl_treenotice
WHERE purposeid = @pid
IF ( @@rowcount = 0 ) --执行结果影响行数为0
BEGIN
ROLLBACK TRAN --回滚
END
ELSE
BEGIN
COMMIT TRAN --提交事务
END
END
END
㈣ sql 回滚语句
事务回滚Transaction Rollback 是指当事务中的某一语句执行失败时将对数据库
的操作恢复到事务执行前或某个指定位置.
如：
begin transaction my_transaction_delete
use pangu
go
delete from department
where dept_id = ’1012’
update employee
set dept_id = ’1001’
where dept_id = ’1012’
if @@error!=0 or @@rowcount=0 then
begin
rollback tran after_delete /* 回滚到保存点after_deletereturn，如果使用rollback my_transaction_delete 则会回滚到事务开始前 */
commit tran
print ‘更新员工信息表时产生错误’
return
end
commit transaction my_transaction_delete
go
㈤ 如何在SQL存储过程中处理错误
一、存储过程中使用事务的简单语法
在存储过程中使用事务时非常重要的，使用数据可以保持数据的关联完整性，在Sql server存储过程中使用事务也很简单，用一个例子来说明它的语法格式：
CreateProcereMyProcere
(@Param1nvarchar(10),
@param2nvarchar(10)
)
AS
Begin
SetNOCOUNTON;
SetXACT_ABORTON;
BeginTran
Deletefromtable1wherename=’abc’;
Insertintotable2values(value1,value2,value3);
CommitTran
End
说明：
1 、使用存储过程执行事物，需要开启XACT_ABORT参数(默认值为Off)，将该参数设置为On，表示当执行事务时，如果出错,会将transcation设置为uncommittable状态，那么在语句块批处理结束后将回滚所有操作；如果该参数设置为Off，表示当执行事务时，如果出错，出错的语句将不会执行，其他正确的操作继续执行。
2、当SET NOCOUNT 为 ON 时，不返回计数（计数表示受 Transact-SQL 语句影响的行数，例如在Sql server查询分析器中执行一个delete操作后，下方窗口会提示（3）Rows Affected）。当 SET NOCOUNT 为 OFF 时，返回计数,我们应该在存储过程的头部加上SET NOCOUNT ON 这样的话，在退出存储过程的时候加上 SET NOCOUNT OFF这样的话，以达到优化存储过程的目的。
二、事务内设置保存点
用户可以在事务内设置保存点或标记。保存点定义如果有条件地取消事务的一部分，事务可以返回的位置。如果将事务回滚到保存点，则必须（如果需要，使用更多的 Transact-SQL 语句和 COMMIT TRANSACTION 语句）继续完成事务，或者必须（通过将事务回滚到其起始点）完全取消事务。若要取消整个事务，请使用 ROLLBACK TRANSACTION transaction_name 格式。这将撤消事务的所有语句和过程。如：
代码
CreateProcereMyProcere
AS
Begin
SetNOCOUNTON;
SetXACT_ABORTON;
begintranok--开始一个事务OK
deletefromrxqzwhereqz='rx015'--删除数据
savetranbcd--保存一个事务点命名为bcd
updateszsetname='李丽s'wherename='李丽'--修改数据
if@@error<>0--判断修改数据有没有出错
begin--如果出错
rollbacktranbcd--回滚事务到BCD的还原点
committranok--提交事务
end
else--没有出错
committranok--提交事务
End
说明：1、@@error判断是否有错误，为0表示没有错误，但是对那种重大错误无法捕捉，而且@@error只能前一句sql语句生效。
三、存储过程使用try…catch捕获错误
在存储过程中可以使用try…catch语句来捕获错误，如下：
CreateProcereMyProcere
(@Param1nvarchar(10),
@param2nvarchar(10)
)
AS
Begin
SetNOCOUNTON;
Begintry
Deletefromtable1wherename=’abc’;
Insertintotable2values(value1,value2,value3);
Endtry
BeginCatch
SELECTERROR_NUMBER()ASErrorNumber,
ERROR_MESSAGE()ASErrorMessage;
EndCatch
End
说明：1、捕获错误的函数有很多，如下：
ERROR_NUMBER() 返回错误号。
ERROR_SEVERITY() 返回严重性。
ERROR_STATE() 返回错误状态号。
ERROR_PROCEDURE() 返回出现错误的存储过程或触发器的名称。
ERROR_LINE() 返回导致错误的例程中的行号。
ERROR_MESSAGE() 返回错误消息的完整文本。该文本可包括任何可替换参数所提供的值，如长度、对象名或时间。
2、有些错误，如sql语句中的表名称输入错误，这是数据库引擎无法解析这个表名称时，所发生的错误在当前的try…catch语句中无法捕获，必须由外层调用该存储过程的地方使用 try…catch来进行捕获。
四、存储过程中事务和try…catch联合使用
在存储过程中使用事务时，如果没有try…catch语句，那么当set xact_abort on时，如果有错误发生，在批处理语句结束后，系统会自动回滚所有的sql操作。当set xact_abort off时，如果有错误发生，在批处理语句结束后，系统会执行所有没有发生错误的语句，发生错误的语句将不会被执行。
在存储过程中使用事务时，如果存在try…catch语句块，那么当捕获到错误时，需要在catch语句块中手动进行Rollback操作，否则系统会给客户端传递一条错误信息。如果在存储过程开始处将set xact_abort on，那么当有错误发生时，系统会将当前事务置为不可提交状态，即会将xact_state()置为-1，此时只可以对事务进行Rollback操作，不可进行提交(commit)操作，那么我们在catch语句块中就可以根据xact_state()的值来判断是否有事务处于不可提交状态，如果有则可以进行rollback操作了。如果在存储过程开始处将set xact_abort off，那么当有错误发生时，系统不会讲xact_state()置为-1，那么我们在catch块中就不可以根据该函数值来判断是否需要进行rollback了，但是我们可以根据@@Trancount全局变量来判断，如果在catch块中判断出@@Trancount数值大于0，代表还有未提交的事务，既然进入catch语句块了，那么还存在未提交的事务，该事务应该是需要rollback的，但是这种方法在某些情况下可能判断的不准确。推荐的方法还是将set xact_abort on，然后在catch中判断xact_state()的值来判断是否需要Rollback操作。
下面我们来看看两个例子：
一．使用Set xact_abort on
CreateprocmyProcere
As
begin
setxact_aborton;
begintry
begintran
insertintoTestStuvalues('Terry','boy',23);
insertintoTestStuvalues('Mary','girl',21);
committran
endtry
begincatch
--在此可以使用xact_state()来判断是否有不可提交的事务,不可提交的事务
--表示在事务内部发生错误了。Xact_state()有三种值：-1.事务不可提交；
--1.事务可提交；0.表示没有事务，此时commit或者rollback会报错。
ifxact_state()=-1
rollbacktran;
endcatch
end
二.使用Set xact_abort off
CreateprocmyProcere
As
begin
setxact_abortoff;
begintry
begintran
insertintoTestStuvalues('Terry','boy',23);
insertintoTestStuvalues('Mary','girl',21);
committran
endtry
begincatch
--在此不可以使用xact_state来判断是否有不可提交的事务
--只可以使用@@Trancount来判断是否有还未提交的事务，未提交的事务未必
--就是不可提交的事务，所以使用@@TranCount>0后就RollBack是不准确的
if@@TranCount>0
rollbacktran;
endcatch
end
另外，对于@@Trancount需要说明的是，begin tran 语句将 @@Trancount加 1。Rollback tran将 @@Trancount递减到 0，但 Rollback tran savepoint_name 除外，它不影响 @@Trancount。Commit tran 或 Commit work 将 @@Trancount 递减 1。
㈥ sql 语句回滚的问题帮帮忙。
用事务处理（比如事务名称是UpdatePrintBill，可以随便起名称）
BEGIN
TRANSACTION
UpdatePrintBill
--中间写你的代码
insert
into
T_BHS_OrderList(OrderList_OrderNum,OrderList_ProId,
OrderList_ProName,OrderList_Pubish_Id,OrderList_SortId,
OrderList_UserID,OrderList_Price,OrderList_Count,
OrderList_CommonPrice,OrderList_Down,OrderList_Time)
select
@OrderNumber,Cart_ProId,Cart_ProName,Cart_Pubish_Id,Cart_Status,Cart_UserId,
Cart_Price,Cart_Count,Cart_CommonPrice,Cart_Down,getdate()
from
dbo.T_BHS_Cart
where
Cart_UserId=@userID
--结束你的代码
IF
@@ERROR
>
0
BEGIN
rollback
TRANSACTION
UpdatePrintBill
return
-1
END
else
begin
COMMIT
TRANSACTION
UpdatePrintBill
return
1
end
㈦ sql存储过程中事务出现错误回滚，那么在回滚之后的语句会执行吗
会的。
一般回滚操作都是写在异常处理，或是sql的最后。如果你的sql中出现错误 ，代码会立即跳转到错误处理代码上执行，比如回滚，但紧接在错误行之后的代码不会执行的。
如
1.update .....;
2.select ......;
3.when Exception
....rollback;
4.insert into .....
以上伪代码，如果行1出错，行2将不会执行，直接跳转到行3，然后行4 也会执行。
㈧ 对于已经执行成功的sql命令，如何回滚
当启动Binlog后，事务会产生Binlog Event，这些Event被看做事务数据的一部分。因此要保证事务的Binlog Event和InnoDB引擎中的数据的一致性。所以带Binlog的CrashSafe要求MySQL宕机重启后能够保证：
- 所有已经提交的事务的数据仍然存在。
- 所有没有提交的事务的数据自动回滚。
- 所有已经提交了的事务的Binlog Event也仍然存在。
- 所有没有提交事务没有记录Binlog Event。
这些要求很好理解，如果重启后数据还在，但是Binlog Event没有了，就没办法复制到其他节点上了。如果重启后，数据没了，但是Binlog Event还在，那么不存在的数据就会被复制到其他节点上，从而导致主从的不一致。
为了保证带Binlog的CrashSafe，MySQL内部使用的两阶段提交(Two Phase Commit)。
2 - MySQL的Two Phase Commit(2PC)
在开启Binlog后，MySQL内部会自动将普通事务当做一个XA事务来处理：
- 自动为每个事务分配一个唯一的ID
- COMMIT会被自动的分成Prepare和Commit两个阶段。
- Binlog会被当做事务协调者(Transaction Coordinator)，Binlog Event会被当做协调者日志。
想了解2PC，可以参考文档：【https://en.wikipedia.org/wiki/Two-phase_commit_protocol。】
- 分布式事务ID(XID)
使用2PC时，MySQL会自动的为每一个事务分配一个ID，叫XID。XID是唯一的，每个事务的XID都不相同。XID会分别被Binlog和InnoDB记入日志中，供恢复时使用。MySQ内部的XID由三部分组成：
- 前缀部分
前缀部分是字符串"MySQLXid"
- Server ID部分
当前MySQL的server_id
- query_id部分
为了保证XID的的唯一性，数字部分使用了query_id。MySQL内部会自动的为每一个语句分配一个query_id，全局唯一。
参考代码：sql/xa。h的struct xid_t结构。
- 事务的协调者Binlog
Binlog在2PC中充当了事务的协调者（Transaction Coordinator）。由Binlog来通知InnoDB引擎来执行prepare，commit或者rollback的步骤。事务提交的整个过程如下：
1. 协调者准备阶段(Prepare Phase)
告诉引擎做Prepare，InnoDB更改事务状态，并将Redo Log刷入磁盘。
2. 协调者提交阶段(Commit Phase)
2.1 记录协调者日志，即Binlog日志。
2.2 告诉引擎做commit。
注意：记录Binlog是在InnoDB引擎Prepare(即Redo Log写入磁盘)之后，这点至关重要。
在MySQ的代码中将协调者叫做tc_log。在MySQL启动时，tc_log将被初始化为mysql_bin_log对象。参考sql/binlog.cc中的init_server_components()：
if (opt_bin_log) tc_log= &mysql_bin_log;
而在事务提交时，会依次执行：
tc_log->prepare()；
tc_log->commit()；
参考代码：sql/binlog.cc中的ha_commit_trans()。当mysql_bin_log是tc_log时，prepare和commit的代码在sql/binlog.cc中：
MYSQL_BIN_LOG::prepare()；
MYSQL_BIN_LOG::commit()；
-协调者日志Xid_log_event
作为协调者，Binlog需要将事务的XID记入日志，供恢复时使用。Xid_log_event有以下几个特点：
- 仅记录query_id
因为前缀部分不变，server_id已经记录在Event Header中，Xid_log_event中只记录query_id部分。
- 标志事务的结束
在Binlog中相当于一个事务的COMMIT语句。
一个事务在Binlog中看起来时这样的：
Query_log_event("BEGIN");DML产生的events; Xid_log_event;
- DDL没有BEGIN，也没有Xid_log_event 。
- 仅InnoDB的DML会产生Xid_log_event
因为MyISAM不支持2PC所以不能用Xid_log_event ，但会有COMMIT Event。
Query_log_event("BEGIN");DML产生的events;Query_log_event("COMMIT");
问题：Query_log_event("COMMIT")和Xid_log_event 有不同的影响吗？
- Xid_log_event 中的Xid可以帮助master实现CrashSafe。
- Slave的CrashSafe不依赖Xid_log_event
事务在Slave上重做时，会重新产生XID。所以Slave服务器的CrashSafe并不依赖于Xid_log_event 。Xid_log_event 和Query_log_event("COMMIT")，只是作为事务的结尾，告诉Slave Applier去提交这个事务。因此二者在Slave上的影响是一样的。
3 - 恢复(Recovery)
这个机制是如何保证MySQL的CrashSafe的呢，我们来分析一下。这里我们假设用户设置了以下参数来保证可靠性：
- 恢复前事务的状态
在恢复开始前事务有以下几种状态：
- InnoDB中已经提交
根据前面2PC的过程，可知Binlog中也一定记录了该事务的的Events。所以这种事务是一致的不需要处理。
- InnoDB中是prepared状态，Binlog中有该事务的Events。
需要通知InnoDB提交这些事务。
- InnoDB中是prepared状态，Binlog中没有该事务的Events。
因为Binlog还没记录，需要通知InnoDB回滚这些事务。
- Before InnoDB Prepare
事务可能还没执行完，因此InnoDB中的状态还没有prepare。根据2PC的过程，Binlog中也没有该事务的events。 需要通知InnoDB回滚这些事务。
- 恢复过程
从上面的事务状态可以看出：恢复时事务要提交还是回滚，是由Binlog来决定的。
- 事务的Xid_log_event 存在，就要提交。
- 事务的Xid_log_event 不存在，就要回滚。
恢复的过程非常简单：
- 从Binlog中读出所有的Xid_log_event
- 告诉InnoDB提交这些XID的事务
- InnoDB回滚其它的事务
㈨ sql语句中用什么语句实现事务的回滚
-开启事务 begin tran --执行操作 update Accounts_UsersExp set TelPhone=123456 where userid=14 --执行错误事务回滚 rollback --如果正确进行事务提交 commit