Let's say I have two stored procedures, Outer and Inner:
CREATE PROCEDURE dbo.Outer
AS
BEGIN
SET NOCOUNT ON;
SET XACT_ABORT ON;
BEGIN TRAN
EXEC Inner
-- Perform additional processing (which should not occur if there is
-- a ROLLBACK in Inner)
...
COMMIT
END;
GO
The Outer stored procedure turns on XACT_ABORT and starts an explicit transaction. It then calls the Inner stored procedure inside the transaction.
CREATE PROCEDURE dbo.Inner
AS
BEGIN
DECLARE #Id INT=(SELECT Id FROM SomeTable WHERE ...);
IF (#Id IS NOT NULL)
ROLLBACK;
INSERT INTO SomeTable(...)
VALUES (...);
END;
GO
The Inner stored procedure performs a check to see if something is present and if it is wants to rollback the entire transaction started in the Outer stored procedure and abort all further processing in both Inner and Outer.
The thing that happens instead of what I expect as outlined above, is that I get the error message:
In Inner:
Transaction count after EXECUTE indicates a mismatching number of
BEGIN and COMMIT statements. Previous count = 1, current count = 0.
In Outer:
The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION.
Clearly, the ROLLBACK even with XACT_ABORT turned on does not stop the flow of execution. Putting a RETURN statement after the ROLLBACK gets us out of Inner, but execution in Outer continues. What do I need to do in order to cause the ROLLBACK to stop all further processing and effectively cause an exit out of Outer?
Thanks for any help.
Issuing the rollback does not abort the batch (Regardless of the XACT_ABORT setting). The batch will automatically abort in your case if an error is thrown with the high enough severity - either system or custom generated via RAISERROR.
You have to implement Exception Handling
Begin Try
Set NOCOUNT ON
SET XACT_ABORT ON
Begin Tran
--Your Code
Commit Tran
End Try
Begin Catch
Rollback Tran
End Catch
Related
We have got a stored procedure that starts a distributed transaction via a linked server with different MS SQL 2008 databases.
We use
SET XACT_ABORT ON;
and also
BEGIN TRY / CATCH blocks
around the transaction to catch any errors and return the error code & message back to the calling client.
However, when a command inside the distributed transaction fails, it seems that the MS DTC is taking over control and our catch block can't rollback "gracefully" and return the error message etc. Instead an error is raised: The Microsoft Distributed Transaction Coordinator (MS DTC) has cancelled the distributed transaction. (Error 1206).
Is there any way that such a distributed tx error is caught by a catch block?
---UPDATE---
Looks like this is a known issue and Microsoft are not going to fix it:
http://connect.microsoft.com/SQLServer/feedback/details/414969/uncatchable-error-when-distributed-transaction-is-aborted
There is a workaround but uses SSIS to call the SP:
http://social.msdn.microsoft.com/Forums/en/sqlnetfx/thread/02e43cad-ac11-45fa-9281-6b4959929be7
You should be able to use XACT_STATE() to rollback the transaction and a RAISERROR coupled with ##ERROR to give you more details
SET NOCOUNT ON
SET XACT_ABORT ON
BEGIN TRY
BEGIN TRANSACTION
..code goes here
COMMIT TRANSACTION;
END TRY
BEGIN CATCH
DECLARE #errormsg VARCHAR(MAX)
SET #errormsg = ##ERROR
-- Test XACT_STATE:
-- If 1, the transaction is committable.
-- If -1, the transaction is uncommittable and should
-- be rolled back.
-- XACT_STATE = 0 means that there is no transaction and
-- a commit or rollback operation would generate an error.
-- Test whether the transaction is uncommittable.
IF (XACT_STATE()) = -1
BEGIN
ROLLBACK TRANSACTION;
END;
-- Test whether the transaction is committable.
IF (XACT_STATE()) = 1
BEGIN
COMMIT TRANSACTION;
END;
RAISERROR(#errormsg, 16, 1)
END CATCH
PROBLEM SUMMARY:
i made error handling that seems to be way too complicated and still does not solve all situations (as there can be situations where transaction gets in uncommitable state). I suspect i:
have missed something important and doing it wrong (can you explain what? and how should i do it then?).
haven't missed anything- just have to accept that error handling is still huge problem in SQL Server.
Can you offer better solution (for described situation below)?
ABOUT MY SITUATION:
I have (couple of) stored procedure in SQL Server, that is called from different places. Can generalize for 2 situations:
Procedure is called from .NET code, transaction is made and handled in SQL procedure
Procedure is called in other procedure (to be more specific- in Service Broker activation procedure), so the transaction is handled by outer procedure.
I made it so, that procedure returns result (1 for success, 0 for failure) + returns message for logging purposes in case of error.
Inside the procedure:
Set XACT_ABORT ON; -- transaction not to be made uncommitable because of triggers.
Declare #PartOfTran bit = 0; -- is used, to save status: 1- if this procedure is part of other transaction or 0- should start new transaction.
If this is part of other tran, then make save point. If not- then begin transaction.
Begin try block- do everything and if there is no mistakes AND if this is not nested transaction do commit. If it is nested transaction- commit will be made in caller procedure.
In case of error: if this is nested transaction and transaction is in commitable state- can do rollback to savepoint "MyTran". if its not part of transaction, rollback transaction called "MyTran". In all other cases- just return error code and message.
Code looks like this:
Create Procedure dbo.usp_MyProcedure
(
-- params here ...
#ReturnCode int out, -- 1 Success, != 1 Error
#ReturnMsg nvarchar(2048) out
)
AS
Begin
Set NoCount ON;
Set XACT_ABORT ON;
Declare #PartOfTran bit = 0;
IF(##TRANCOUNT > 0)
Begin
SET #PartOfTran = 1;
SAVE TRAN MyTran;
END
Else
BEGIN TRAN MyTran;
Begin Try
-- insert table1
-- update table2
-- ....
IF(#PartOfTran = 0)
COMMIT TRAN MyTran;
Select #ReturnCode = 1, #ReturnMsg = Null;
End Try
Begin Catch
IF (XACT_STATE() = 1 And #PartOfTran = 1) OR #PartOfTran = 0
Rollback Tran MyTran;
Select #ReturnCode = 0, #ReturnMsg = ERROR_MESSAGE();
End Catch
End
OTHER LITERATURE:
From my favorite bloggers have seen:
sommarskog - but i don't like that "outer_sp" has line "IF ##trancount > 0 ROLLBACK TRANSACTION", because in my case- outer procedure can be called in transaction, so in that case i have "Transaction count after EXECUTE indicates a mismatching number of BEGIN and COMMIT statements. Previous count = 1, current count = 0."
rusanu - actually almost the same as i wrote here (maybe idea comes from that blog post- i wrote my solution based on all i have read about this subject). This blog post still does not solve what should i do with uncommitable transactions. This is problem in case of Service Broker. How can i make correct logging of error message, if i have to rollback uncommitable transaction? i have ideas about this, but all of them seems like workarounds not elegant solutions.
You won't be able to achieve a solution that rolls back only the work done in usp_MyProcedure in any condition. Consider the most obvious example: deadlock. When your are notified of exception 1205 (you've been chosen as a deadlock victim) the transaction has already rolled back ( in order to allow progress). As error handling goes, the only safe option is to further raise and re-throw so that the caller has a chance to react. The 'uncommittable transaction' is just a variation on that theme: there is just no way error handling can recover from such a situation in a manner that is sensible for the caller, when the caller has started a transaction. The best thing is to raise (re-throw). This is why I used the pattern you've seen in my blog at Exception HAndling and Nested Transactions
Considering this in Service Broker context it means that there is no completely bullet proof, exception safe message handling routine. If you hit an uncommitable transaction (or a transaction that has already rolled back by the time you process the catch block, like 1205 deadlock) then your whole batch of received messages will have to rollback. Logging is usualy done in such situations after the outermost catch block (usually locate din the activated procedure). Here is pseudo code of how this would work:
usp_myActivatedProc
as
#commited = false;
#received = 0;
#errors = 0;
begin transaction
begin try
receive ... into #table;
#received = ##row_count;
foreach message in #table
save transaction
begin try
process one message: exec usp_myProcedure #msg
end try
begin catch
if xact_state()=1
rollback to savepoint
#errors += 1;
-- decide what to do with failed message, log
-- this failure may still be committed (receive won't roll back yet)
else
-- this is a lost cause, re-throw
raiserror
end catch
fetch next #table
endfor
commit
#commited = true;
end try
catch
#error_message = error_message();
if xact_state() != 0
rollback
end catch
if #commited = false
begin
insert into logging 'failed', #received, #error_message
end
-- insert table1
IF ##ERROR > 0
GOTO _FAIL
-- update table2
-- ....
IF ##ERROR > 0
GOTO _FAIL
GOTO _SUCCESS
_ERROR:
ROLLBACK TRAN
SET #ReturnCode = 1
RETURN
_FAIL:
ROLLBACK TRAN
SET #ReturnCode = 1
RETURN
_SUCCESS:
COMMIT TRAN
at the end of the tran insert the
GOTO _SUCCESS
so it will commit the tran if didnt hit any errors.
AND all of ur insert or update statement inside the tran insert the
IF ##ERROR > 0
GOTO _FAIL
so when it hit error.. it will go to the
_FAIL:
ROLLBACK TRAN
SET #ReturnCode = 1
RETURN
and u can set all ur return value at there
I have a procedure which is of the below sort
BEGIN TRY
BEGIN TRAN
...transactins A....
BEGIN TRY
.... Transaction B ....
END TRY
BEGIN CATCH
.... Set variables and print messages ....
END CATCH
....Transaction C
COMMIT TRAN
END TRY
BEGIN CATCH
ROLLBACK TRAN
...Transaction D
END CATCH
The Transaction B is throwing an error and due to this the process is going into an uncommitable state and throwing the below error. I have checked the XACT_STATE() Value it is -1
Msg 3930, Level 16, State 1, Procedure xxxxxxxx, Line 70
The current transaction cannot be committed and cannot support operations that write to the log file. Roll back the transaction.
Is there any other way to over come this by some how skipping the transaction B and executing the transactions C
The whole point of using a transaction is that the operations within it either all succeed or all fail. If you want to isolate Transaction C from the affects of the failure of Transaction B, then use separate BEGIN TRAN/COMMIT/ROLLBACK operations for each.
I need to perform several inserts in a single atomic transaction. For example:
start transaction;
insert ...
insert ...
commit;
However when MySQL encounters an error it aborts only the particular statement that caused the error. For example, if there is an error in the second insert statement the commit will still take place and the first insert statement will be recorded. Thus, when errors occur a MySQL transaction is not really a transaction. To overcome this problem I have used an error exit handler where I rollback the transaction. Now the transaction is silently aborted but I don't know what was the problem.
So here is the conundrum for you:
How can I both make MySQL abort a transaction when it encounters an error, and pass the error code on to the caller?
How can I both make MySQL abort a transaction when it encounters an error, and pass the error code on to the caller?
MySQL does pass error code to the caller and based on this error code the caller is free to decide whether it wants to commit work done up to the moment (ignoring the error with this particular INSERT statement) or to rollback the transaction.
This is unlike PostgreSQL which always aborts the transaction on error and this behavior is a source of many problems.
Update:
It's a bad practice to use an unconditional ROLLBACK inside the stored procedures.
Stored procedures are stackable and transactions are not, so a ROLLBACK within a nested stored procedure will roll back to the very beginning of the transaction, not to the state of the stored procedure execution.
If you want to use transactions to restore the database state on errors, use SAVEPOINT constructs and DECLARE HANDLER to rollback to the savepoints:
CREATE PROCEDURE prc_work()
BEGIN
DECLARE EXIT HANDLER FOR SQLEXCEPTION ROLLBACK TO sp_prc_work;
SAVEPOINT sp_prc_work;
INSERT …;
INSERT …;
…
END;
Failure in either insert will roll back all changes made by the procedure and exit it.
Using Mr. Quassnoi's example, here's my best approach to catching specific errors:
The idea is to use a tvariable to catch a simple error message, then you can catch sql states you think may happen to save custom messages to your variable:
DELIMITER $$
DROP PROCEDURE IF EXISTS prc_work $$
CREATE PROCEDURE prc_work ()
BEGIN
DECLARE EXIT HANDLER FOR SQLSTATE '23000'
BEGIN
SET #prc_work_error = 'Repeated key';
ROLLBACK TO sp_prc_work;
END;
DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN
SET #prc_work_error = 'Unknown error';
ROLLBACK TO sp_prc_work;
END;
START TRANSACTION;
SAVEPOINT sp_prc_work;
INSERT into test (id, name) VALUES (1, 'SomeText');
COMMIT;
END $$
DELIMITER ;
Then you just do your usual call, and do a select statement for the variable like:
call prc_work(); select #prc_work_error;
This will return either NULL if no error, or the message error in case of an error. If you need persistent error message you can optionally create a table to store it.
It's tedious and not very flexible because requires a DECLARE EXIT HANDLER segment for each status code you want to catch, it won't also show detailed error messages but hey, it works.
I can't find an optimal way to use transactions in a MySql Stored Procedure. I want to ROLLBACK if anything fails:
BEGIN
SET autocommit=0;
START TRANSACTION;
DELETE FROM customers;
INSERT INTO customers VALUES(100);
INSERT INTO customers VALUES('wrong type');
COMMIT;
END
1) Is autocommit=0 required?
2) If the second INSERT breaks (and it does of course) the first INSERT is not rolled back. The procedure simply continues down to the COMMIT. How can I prevent this?
3) I've found I can DECLARE HANDLER, should I use this instruction or is there a simpler way to say that if any command fails, the stored procedure should ROLLBACK and fail too?
DECLARE HANDLER works fine, but since I have MySql version 5.1 I can't use RESIGNAL. So if an error occurs, the caller won't be notified:
DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN
ROLLBACK;
-- RESIGNAL; not in my version :(
END;
START TRANSACTION;
Answer to 1: You don't need to set autocommit=0
With START TRANSACTION, autocommit remains disabled until you end the
transaction with COMMIT or ROLLBACK. The autocommit mode then reverts
to its previous state.
http://dev.mysql.com/doc/refman/5.6/en/commit.html
Different Approach to Answer 2: You could use a boolean variable to know if you should COMMIT or ROLLBACK. For example:
BEGIN
DECLARE `should_rollback` BOOL DEFAULT FALSE;
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION SET `should_rollback` = TRUE;
START TRANSACTION;
DELETE FROM customers;
INSERT INTO customers VALUES(100);
INSERT INTO customers VALUES('wrong type');
IF `should_rollback` THEN
ROLLBACK;
ELSE
COMMIT;
END IF;
END
Or, you could use your very usefull 3)