SET option XACT_ABORT and SQL Server Transaction

SET option XACT_ABORT and SQL Server Transaction

Error is something which nobody wants to have in their software/code though, as a developer, we used to see errors so many times no matter whether it is development environment or live environment.

If we talk specifically about SQL Server, we used to come across following types of errors in SQL Server.

1.) Statement Terminate:

2.) Scope Terminate:

3.) Batch Terminate:

4.) Connection Terminate:

People tend to use “TRANSACTION” when they are using DML command, especially more then one DML operation based on each other. This is completely fine. I, too, tend to use it but we never like to hang the transaction as it is. We may want to ROLLBACK all DML statement if any run-time error come across in-between execution of any DML statement given in one batch.

We may use “ROLLBACK” statement and TRY…CATCH to manage our transaction even sometime bigger severity runtime error occurs and your code don’t follow the CATCH block either and hence ROLLBACK TRANSACTION never executes so If we have XACT_ABORT option set to ON, we can be sure that if run-time error occurs, we will have all DML transaction rolled back.

Let us understand this by following example:

Creating sample temporary table with some sample data:

[sourcecode language=”sql”]
IF OBJECT_ID(‘tempdb..#TestingTHROWCommand’) IS NOT NULL
DROP TABLE #TestingTHROWCommand

CREATE TABLE #TestingTHROWCommand
(
ID INT IDENTITY(1,1)
,Name VARCHAR(50)
,OvertimeAmount INT
)

INSERT INTO #TestingTHROWCommand
SELECT ‘Ritesh Shah’,15 UNION ALL
SELECT ‘Teerth Shah’,0 UNION ALL
SELECT ‘Rajan Jain’,9
GO
[/sourcecode]

Now we will execute one TSQL code block which will update our temp table twice. First UPDATE statement is fine but second will generate the error. Keep in mind that we neither have ROLLBACK nor we have XACT_ABORT ON in following block:

[sourcecode language=”sql”]
BEGIN TRY
BEGIN TRANSACTION

UPDATE #TestingTHROWCommand
SET OvertimeAmount=95/OvertimeAmount
WHERE ID=1

UPDATE #TestingTHROWCommand
SET OvertimeAmount=95/OvertimeAmount
WHERE ID=2

COMMIT TRANSACTION
END TRY

BEGIN CATCH
SELECT ERROR_NUMBER(),ERROR_MESSAGE(),ERROR_LINE()
END CATCH
GO
[/sourcecode]

Can you imagine what would happens to both the UPDATE? Let us see what happened to both UPDATE by executing simple SELECT statement on temp table.

[sourcecode language=”sql”]
SELECT * FROM #TestingTHROWCommand
GO
[/sourcecode]

Here is the output I have received for my SELECT statement.

WithoutXACT_Abort

You can see that there wasn’t any error in first UPDATE so that value is updated and second UPDATE had an error and hence it is not updated obviously. We may want that if error occurs, neither of the records should be updated. We might use CATCH block for ROLLBACK TRANSACTION but what, if error was with high severity and it doesn’t falls under CATCH statement? So it is better to be in safe side and have XACT_ABORT with ON status in every code block wherever we are using DML statements with TRANSACTION.

Let us insert all original values in our temp table.

[sourcecode language=”sql”]
TRUNCATE TABLE #TestingTHROWCommand
GO

INSERT INTO #TestingTHROWCommand
SELECT ‘Ritesh Shah’,15 UNION ALL
SELECT ‘Teerth Shah’,0 UNION ALL
SELECT ‘Rajan Jain’,9
GO
[/sourcecode]

Now we can execute same UPDATE statements with XACT_ABORT.

[sourcecode language=”sql”]
SET XACT_ABORT ON;
BEGIN TRY
BEGIN TRANSACTION

UPDATE #TestingTHROWCommand
SET OvertimeAmount=95/OvertimeAmount
WHERE ID=1

UPDATE #TestingTHROWCommand
SET OvertimeAmount=95/OvertimeAmount
WHERE ID=2

COMMIT TRANSACTION
END TRY

BEGIN CATCH
SELECT ERROR_NUMBER(),ERROR_MESSAGE(),ERROR_LINE()
END CATCH
GO
[/sourcecode]

As soon as I ran above code block, I greeted with following error:

WithXACT_Abort

[sourcecode language=”sql”]
Msg 3998, Level 16, State 1, Line 1
Uncommittable transaction is detected at the end of the batch. The transaction is rolled back.
[/sourcecode]

Can you imagine what would happens to both the UPDATE? Let us see what happened to both UPDATE by executing simple SELECT statement on temp table.Here is the output I have received for my SELECT statement.

[sourcecode language=”sql”]
SELECT * FROM #TestingTHROWCommand
GO
[/sourcecode]

WithXACT_AbortSELECT

You can see that none of the values are updated. XACT_ABORT did ROLLBACK by its own even without explicitly written ROLLBACK statements. I am not saying that don’t put ROLLBACK statements. It MUST be there but XACT_ABORT can be useful in certain situation we might have missed to handle.

If you are interested to read error handling article I have written previously, have a look at list below:

Error handling with “THROW” command in SQL Server 2012 (Click Here)
List of Errors and severity level in SQL Server with catalog view sysmessages (Click Here)
Create custom error message by sys.sp_addmessage in SQL Server 2012 (Click Here)
Importance of transaction in SQL Server (Click Here)
Capture and log error of TSQL code in SQL Server 2012 (Click Here)
SET option XACT_ABORT and SQL Server Transaction (Click Here)

If you like this article, do like “Extreme-Advice” page in Facebook.

Reference: Ritesh Shah

http://Extreme-Advice.com

http://www.sqlhub.com

Note: Microsoft Books online is a default reference of all articles

Capture and log error of TSQL code in SQL Server 2012

Capture and log error of TSQL code in SQL Server 2012

SQL Server provides a robust way to capture error with TRY….CATCH but I wanted to have centralized information about error to maintain history and for debugging purpose so that I have created one stored procedure to log error information in one table. I used to call that stored procedure which capture error in my every stored procedure.

I have created “[dbo].[usp_LogErrorHistory] ” stored procedure which logs all errors in “[dbo].[ErrorHistory]” table. I used to call “[dbo].[usp_LogErrorHistory] ” SP in every stored procedure I create and hence I have, now, one central location (“[dbo].[ErrorHistory]” table) where I can go and look for total number of error withing given time period and for given objects.

Let us create “[dbo].[ErrorHistory]” table and “[dbo].[usp_LogErrorHistory] ” stored procedure with following TSQL:

[sourcecode language=”sql”]
CREATE TABLE [dbo].[ErrorHistory](
[ErrorLogID] [int] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL,
[ErrorTime] [datetime] NOT NULL DEFAULT GETDATE(),
[UserName] [sysname] NOT NULL,
[ErrorNumber] [int] NOT NULL,
[ErrorSeverity] [int] NULL,
[ErrorState] [int] NULL,
[ErrorProcedure] [nvarchar](126) NULL,
[ErrorLine] [int] NULL,
[ErrorMessage] [nvarchar](4000) NOT NULL,
[ContextInfo] [varbinary](max) NULL,
CONSTRAINT [PK_ErrorLog_ErrorLogID] PRIMARY KEY CLUSTERED
(
[ErrorLogID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
)
GO

CREATE PROCEDURE [dbo].[usp_LogErrorHistory]
— contains the ErrorLogID of the row inserted
@ErrorLogID [int] = 0 OUTPUT
AS
BEGIN
SET NOCOUNT ON;
— Output parameter value of 0 indicates that error
— information was not logged
SET @ErrorLogID = 0;

BEGIN TRY
— Return if there is no error information to log

IF ERROR_NUMBER() IS NULL
RETURN;

— Return if inside an uncommittable transaction.
— Data insertion/modification is not allowed when
— a transaction is in an uncommittable state.
IF XACT_STATE() = -1
BEGIN
PRINT ‘Cannot log error since the current transaction is in an uncommittable state. ‘
+ ‘Rollback the transaction before executing usp_LogErrorHistory in order to successfully log error information.’;
RETURN;
END

INSERT [dbo].[ErrorHistory]
(
[UserName],
[ErrorNumber],
[ErrorSeverity],
[ErrorState],
[ErrorProcedure],
[ErrorLine],
[ErrorMessage],
[ContextInfo]
)
VALUES
(
CONVERT(sysname, CURRENT_USER),
ERROR_NUMBER(),
ERROR_SEVERITY(),
ERROR_STATE(),
ERROR_PROCEDURE(),
ERROR_LINE(),
ERROR_MESSAGE(),
CONTEXT_INFO()
);

— Pass back the ErrorLogID of the row inserted
SET @ErrorLogID = @@IDENTITY;
END TRY
BEGIN CATCH
PRINT ‘An error occurred in stored procedure usp_LogErrorHistory: ‘;
RETURN -1;
END CATCH
END;
GO
[/sourcecode]

Once we are done with above given SP and table, we will create one more user stored procedure which we will execute and it will generate an error which will be logged in our error history table.

[sourcecode language=”sql”]
CREATE PROC TestErrorLog1
AS
BEGIN
–Specifies whether SQL Server automatically rolls back the current transaction
–when a Transact-SQL statement raises a run-time error.
–this is the reason I keep having XACT_ABORT in all my SP when transaction is used
SET XACT_ABORT ON;

–used to keep following statement in all my SP for performance point of view
SET NOCOUNT ON

BEGIN TRY
–I am not performing any DML statement here though I have kept transaction here
–to demonstrate the usage
BEGIN TRANSACTION
SELECT 1/0
COMMIT TRANSACTION
END TRY
BEGIN CATCH
IF @@TRANCOUNT>0
ROLLBACK

–to log the error
EXEC [dbo].[usp_LogErrorHistory] ;

–to show the error to the end user
THROW
END CATCH
END
GO
[/sourcecode]

Now this is a time to check functionality of our error SP by executing following TSQL script:

[sourcecode language=”sql”]
–execut TestErrorLog1 SP to confirm whether error is being logged or not
EXECUTE TestErrorLog1
GO
[/sourcecode]

Okay so I hope your first error after creating this environment has logged. Let us confirm it by executing SELECT query in Error History table.

[sourcecode language=”sql”]
–Looking at [dbo].[ErrorHistory] table to see captured error:
SELECT * FROM [dbo].[ErrorHistory]
[/sourcecode]

Here is the output of my SELECT statement on ErrorHistory table.

1Error

Please note that This code should work in older version of SQL Server eg: SQL Server 2008 or 2008 R2 as well. You have to use RAISERROR instead of THROW statement.

If you like this article, do like “Extreme-Advice” page in Facebook.

Reference: Ritesh Shah

http://Extreme-Advice.com

http://www.sqlhub.com

Note: Microsoft Books online is a default reference of all articles.