㈠ 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