存儲過程回滾事務

① 存儲過程的問題 回滾

看你程序怎麼寫的，如果循環中每次插入每次提交自然回滾不了了，一般來說是整個作為一個事務，在發生錯誤異常處理時候做ROLLBACK。存儲過程自己沒有回滾功能，要你在程序中控制事務完整性的。如果你不寫commit也不寫rollback的話，自動作為一個事務整體會失敗，事務自動回滾，如果執行成功，事務結束則自動提交。

② 存儲過程與事物回滾的問題

答案是：任何情況下的事務嵌套.只要任何地方出錯,全回滾.

事務組合一系列任務為一個執行單元。每個事務以特定的任務開始，以特定的任務結束。當所有的任務成功時事務成功，當任何一個任務失敗時，事務失敗。所以一個事務只有兩個結果：失敗或成功。

請參考:《sql Server的事務和錯誤處理》：
http://www.it118.org/specials/c9fba99e-4401-49cf-8256-ac3c1a34c0d9/33827942-5e09-42f9-a409-235a099616b3.htm

③ sqlserver 存儲過程事務回滾怎麼寫

begin tran
。。。。。。
在存儲過程後面加上:
if @@error<>0
rollback tran
else
commit tran

④ SQL存儲過程，如何回滾啊

當 SET XACT_ABORT 為 ON 時，如果執行 Transact-SQL 語句產生運行時錯誤，則整個事務將終止並回滾。
當 SET XACT_ABORT 為 OFF 時，有時只回滾產生錯誤的 Transact-SQL 語句，而事務將繼續進行處理。如果錯誤很嚴重，那麼即使 SET XACT_ABORT 為 OFF，也可能回滾整個事務。OFF 是默認設置。

編譯錯誤（如語法錯誤）不受 SET XACT_ABORT 的影響。

對於大多數 OLE DB 提供程序（包括 SQL Server），必須將隱式或顯示事務中的數據修改語句中的 XACT_ABORT 設置為 ON。唯一不需要該選項的情況是在提供程序支持嵌套事務時。有關詳細信息，請參閱 分布式查詢和分布式事務。

SET XACT_ABORT 的設置是在執行或運行時設置，而不是在分析時設置。

示例
下列代碼示例導致在含有其他 Transact-SQL 語句的事務中發生外鍵沖突錯誤。在第一個語句集中產生錯誤，但其他語句均成功執行且事務成功提交。在第二個語句集中，將 SET XACT_ABORT 設置為 ON。這導致語句錯誤使批處理終止，並使事務回滾。

復制代碼
USE AdventureWorks;
GO
IF OBJECT_ID(N't2', N'U') IS NOT NULL
DROP TABLE t2;
GO
IF OBJECT_ID(N't1', N'U') IS NOT NULL
DROP TABLE t1;
GO
CREATE TABLE t1
(a INT NOT NULL PRIMARY KEY);
CREATE TABLE t2
(a INT NOT NULL REFERENCES t1(a));
GO
INSERT INTO t1 VALUES (1);
INSERT INTO t1 VALUES (3);
INSERT INTO t1 VALUES (4);
INSERT INTO t1 VALUES (6);
GO
SET XACT_ABORT OFF;
GO
BEGIN TRANSACTION;
INSERT INTO t2 VALUES (1);
INSERT INTO t2 VALUES (2); -- Foreign key error.
INSERT INTO t2 VALUES (3);
COMMIT TRANSACTION;
GO
SET XACT_ABORT ON;
GO
BEGIN TRANSACTION;
INSERT INTO t2 VALUES (4);
INSERT INTO t2 VALUES (5); -- Foreign key error.
INSERT INTO t2 VALUES (6);
COMMIT TRANSACTION;
GO
-- SELECT shows only keys 1 and 3 added.
-- Key 2 insert failed and was rolled back, but
-- XACT_ABORT was OFF and rest of transaction
-- succeeded.
-- Key 5 insert error with XACT_ABORT ON caused
-- all of the second transaction to roll back.
SELECT *
FROM t2;
GO

⑤ JDBC調用存儲過程,存儲過程中事務回滾,報錯

ConnCloseThread中關閉連接的時候，不是立刻返回的。Connection.close()會觸發Connection.commit()，而因為調用的存儲過程中，存儲過程起了自己的事務，connection.commit()必須等到存儲過程結束才能完成(這個是microsoft論壇上看到的)。如果所有connection.close()都等到tx commit或rollback完成才執行的話，這個問題就不會出現了
從測試結果來看，凡是close connection耗時比execute statement短的，連接（物理連接）都會報出該問題。分析原因：通過weblogic datasource獲取的connection並不是物理connection，而是由weblogic wrapped的connection。這些conection在被close後，並不會關閉物理連接，而只是將物理連接還池。我們對connection的所有操作，最終都會被delegated到底層物理連接上，即commit()，rollback()最終都是在物理連接上執行。如果上面的connection.close()，底層物理連接沒有等到存儲過程事務結束就返回的話，那麼物理連接上應該還帶有此次操作的事務，而weblogic這邊不會關系物理連接的情況，直接將連接放入connection pool供其它客戶端使用。這時候如果設定了test on reserve的話，下次客戶端從data source獲取連接時，weblogic會檢查這個物理連接，作一個select操作的，這個有問題的連接就會暴露出來，也就是上面的異常。這個問題如果使用driver manager來獲取連接的話（如果每次都關閉的話），則不會出現，因為使用的物理連接每次都是不同的。還好，weblogic會幫忙重新創建有問題的連接。原因大概了解了，但這是誰的問題呢？ 為什麼connection.close()不等存儲過程的事務結束？

結論：一般而言，我們不建議通過JDBC調用存儲過程的時候，在存儲過程中定義事務，應該將tx的管理工作交給jdbc去做。 non-xa如此，xa亦如此，畢竟事務嵌套了以後，管理起來是個問題，完整性更是個問題。

⑥ 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存儲過程中事務出現錯誤回滾，那麼在回滾之後的語句會執行嗎

會的。

一般回滾操作都是寫在異常處理，或是sql的最後。如果你的sql中出現錯誤 ，代碼會立即跳轉到錯誤處理代碼上執行，比如回滾，但緊接在錯誤行之後的代碼不會執行的。

如
1.update .....;

2.select ......;
3.when Exception
....rollback;
4.insert into .....

以上偽代碼，如果行1出錯，行2將不會執行，直接跳轉到行3，然後行4 也會執行。

⑧ 存儲過程回滾 急

BEGIN TRY

END
BEGIN CATCH
END CATCH
用這個試試呢

⑨ SQL Server存儲過程裡面是更新某個表，那麼如何在這個基礎上增加更新失敗時的事務回滾語句

更新失敗不需要回滾因為都沒執行成功，一般是多個插入，更新操作需要事務處理

⑩ Oracle怎麼顯式開啟事務，開始事務跟鎖有什麼關系，在存儲過程中有時怎麼開啟和提交，回滾事務的

oracle使用語句savepoint sp_begintran開啟顯式事務，鎖本身和事務是沒有關系的，只要是資料庫的操作都會產生鎖。處於事務中的SQL語句只有這個事務提交（commit）之後，事務中的SQL語句影響的表記錄上的鎖才會釋放。鎖常見有共享鎖（select語句產生）和排它鎖（DML語句產生），如果一個表上載入有共享鎖，還可以疊加共享鎖，但不能疊加排它鎖。如果一個表上載入有排他鎖，就什麼鎖都不能加了，也就是說如果DML語句佔用過多的時間，這些資料庫效率就不高，就需要優化，當然select語句性能低了也不行。
每個存儲過程可以不用顯式事務，它本身就為你開啟了一個隱式事務，如果需要開啟顯示事務，就通過savepoint sp_begintran開啟，無論是不是顯式還是隱式事務，你都得通過commit work提交事務，通過exception捕捉SQL語句異常，在異常發生時需要回滾事務（rollback work）。