Nested stored procedure and transaction scope - sql-server-2008

I have a main working procedure and an accompanying logging procedure. I'm looking for verification on what my assumptions are with sql server 2008. The desired result is that SP1 does whatever work it can do and calls SP2 along the way to log progress. SP2 work is committed regardless of whether or not SP1 encounters an error that would cause it's transaction to rollback.
Does what I have look safe? Do I need to name transaction in SP2 differently?
------------------------------------------------------- SP1 pseudocode
BEGIN TRY
BEGIN TRANSACTION
-- Do stuff
-- log progress
exec SP2( getutcdate(), 'source_is_sp1','message for progress');
-- Do more stuff
-- log progress
exec SP2( getutcdate(), 'source_is_sp1','message for progress');
-- etc
COMMIT TRANSACTION
RETURN 0
END TRY
BEGIN CATCH
-- error handling not important
ROLLBACK TRANSACTION
return #StepNumber -- not important
END CATCH
------------------------------------------------------- SP2
CREATE PROCEDURE [dbo].[SP2]
#Source as nvarchar(100),
#Timestamp as datetime,
#Message as nvarchar(4000)
AS
BEGIN
SET NOCOUNT ON;
IF #Timestamp is null
BEGIN
set #Timestamp = GETUTCDATE();
END
IF #Source IS NOT NULL AND #Message IS NOT NULL
BEGIN
BEGIN TRANSACTION;
INSERT INTO LOG(LOGTIMESTAMP, SOURCEVCH, MESSAGEVCH)
VALUES (#Timestamp, #Source, #Message);
COMMIT TRANSACTION;
END
END

Related

Nested procedure - Transaction count after EXECUTE indicates a mismatching number of BEGIN and COMMIT

I get an error
Custom error message. Transaction count after EXECUTE indicates a mismatching number of BEGIN and COMMIT statements. Previous count = 1, current count = 0. Transaction count after EXECUTE indicates a mismatching number of BEGIN and COMMIT statements. Previous count = 1, current count = 0.
My SQL Code is following
Procedure 1
CREATE PROCEDURE [dbo].[spProcedure1]
#Id int
WITH EXECUTE AS OWNER
AS
BEGIN
BEGIN TRY
BEGIN TRANSACTION
EXEC spProcedure2 #Id
-- Code ommited, Next procedures execution
COMMIT TRANSACTION
END TRY
BEGIN CATCH
IF ##TRANCOUNT > 0
ROLLBACK TRANSACTION
-- Code ommited, saving error to Log table
RAISERROR(#errorMessage, #errorSeverity, #errorState);
END CATCH
END
Procedure 2
CREATE PROCEDURE [dbo].[spProcedure2]
#Id int
WITH EXECUTE AS OWNER
BEGIN
BEGIN TRY
-- Check if record exists
IF NOT EXISTS(SELECT * FROM dbo.Table t WHERE t.Id = #Id)
BEGIN
-- stop procedure due to user error
RAISERROR('Custom error message.',16,1)
RETURN
END
-- Code ommited, DML operation
END TRY
BEGIN CATCH
-- Code ommited, saving error to Log table
RAISERROR(#errorMessage, #errorSeverity, #errorState);
END CATCH
END
I am not sure how to handle transaction in the Procedure 2 to obey this error ?

How to rollback transaction in new query window

Hi i have one sp where i used try catch with transaction. below is the code
USE [Securtimeweb2.1]
GO
/****** Object: StoredProcedure [dbo].[UpdateCompany] Script Date: 7/6/2015 12:14:27 PM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
-- =============================================
-- Author: <Author,,Name>
-- Create date: <Create Date,,>
-- Description: <Description,,>
-- =============================================
ALTER PROCEDURE [dbo].[UpdateCompany]
(
#CompanyCode varchar(max),
#NewCompCode varchar(max)=null,
#TRANSVAL VARCHAR(MAX)
)
as
BEGIN
BEGIN TRY
BEGIN TRAN #TRANSVAL
update BranchMaster set CompanyCode=#NewCompCode Where CompanyCode=#CompanyCode
COMMIT TRAN #TRANSVAL
END TRY
BEGIN CATCH
SELECT ERROR_MESSAGE() AS strMessage
ROLLBACK TRAN #TRANSVAL
END CATCH
END
then i use this code to run this sp in another query window
EXEC UpdateCompany '002','003','TRAN1'
so after using this in one another query window i am trying to rollback the transaction which is
DECLARE #TRAN VARCHAR(MAX)='TRAN1'
BEGIN TRAN #TRAN
ROLLBACK TRAN #TRAN
so here we can see i given some name for the transaction and trying to rollback with the same name but it's not getting rollback.
Am i doing anything wrong here??
Use This Links To Know How Transaction Works
http://www.sqlservercurry.com/2011/01/rollback-transaction-in-sql-server.html
I use following standard, maybe it can help :
BEGIN TRAN
BEGIN TRY
--YOUR SQL STATEMENTS
END TRY
BEGIN CATCH
SELECT ERROR_MESSAGE() AS [STATUS]
ROLLBACK TRAN
END CATCH
IF ##TRANCOUNT > 0
BEGIN
COMMIT TRAN
SELECT 'SUCCESS' AS [STATUS]
END

SQL Server - Nested transactions in a stored procedure

Lets say this is the situation:
[Stored Proc 1]
BEGIN
BEGIN TRANSACTION
...
exec sp 2
COMMIT
END
Now, if SP 2 - rolls back for whatever reason, does SP 1 - commit or rollback or throw exception?
Thanks.
It is possible for the work done by SP2 to be rolled back and not loose the work done by SP1. But for this to happen, you must write your stored procedures using a very specific pattern, as described in Exception handling and nested transactions:
create procedure [usp_my_procedure_name]
as
begin
set nocount on;
declare #trancount int;
set #trancount = ##trancount;
begin try
if #trancount = 0
begin transaction
else
save transaction usp_my_procedure_name;
-- Do the actual work here
lbexit:
if #trancount = 0
commit;
end try
begin catch
declare #error int, #message varchar(4000), #xstate int;
select #error = ERROR_NUMBER(), #message = ERROR_MESSAGE(), #xstate = XACT_STATE();
if #xstate = -1
rollback;
if #xstate = 1 and #trancount = 0
rollback
if #xstate = 1 and #trancount > 0
rollback transaction usp_my_procedure_name;
raiserror ('usp_my_procedure_name: %d: %s', 16, 1, #error, #message) ;
end catch
end
Not all errors are recoverable, there are a number of error conditions that a transaction cannot recover from, the most obvious example being deadlock (your are notified of the deadlock exception after the transaction has already rolled back). Both SP1 and SP# have to be written using this pattern. If you have a rogue SP, or you want to simple leverage existing stored procedures that nilly-willy issue ROLLBACK statements then your cause is lost.
There are no autonomous transactions in SQL Server. You may see ##TRANCOUNT increase beyond 1, but a rollback affects the whole thing.
EDIT asked to point to documentation. Don't know of the topic that documents this explicitly, but I can show it to you in action.
USE tempdb;
GO
Inner proc:
CREATE PROCEDURE dbo.sp2
#trip BIT
AS
BEGIN
SET NOCOUNT ON;
BEGIN TRANSACTION;
PRINT ##TRANCOUNT;
IF #trip = 1
BEGIN
IF ##TRANCOUNT > 0
ROLLBACK TRANSACTION;
END
ELSE
BEGIN
IF ##TRANCOUNT > 0
COMMIT TRANSACTION;
END
PRINT ##TRANCOUNT;
END
GO
Outer proc:
CREATE PROCEDURE dbo.sp1
#trip BIT
AS
BEGIN
SET NOCOUNT ON;
BEGIN TRANSACTION;
PRINT ##TRANCOUNT;
BEGIN TRY
EXEC dbo.sp2 #trip = #trip;
END TRY
BEGIN CATCH
PRINT ERROR_MESSAGE();
END CATCH
PRINT ##TRANCOUNT;
IF ##TRANCOUNT > 0
COMMIT TRANSACTION;
PRINT ##TRANCOUNT;
END
GO
So now let's call it and let everything commit:
EXEC dbo.sp1 #trip = 0;
Results:
12110
Now let's call it and roll back the inner procedure:
EXEC dbo.sp1 #trip = 1;
Results:
120 <-- notice that a rollback here rolled back both
Transaction count after EXECUTE indicates a mismatching number
of BEGIN and COMMIT statements. Previous count = 1, current count = 0.
00
If SP2 rolls back the transaction, SP1 will rollback as well.
See: http://msdn.microsoft.com/en-US/library/ms187844(v=sql.105).aspx for details.
In nested transactions, if any of the inner transations rolls back, all its outer transaction will rollback.
Here is a quick and dirty way to nest transactions in stored procedures (using the code from Aaron's answer) that can be useful sometimes. It uses a default parameter to indicate to the inner procedure if it is a nested call, and returns a success/fail result to the outer procedure.
CREATE PROCEDURE dbo.sp2
#trip BIT,
#nested BIT = 0
AS
BEGIN
SET NOCOUNT, XACT_ABORT ON
IF #nested = 0 BEGIN TRAN
PRINT ##TRANCOUNT
IF #trip = 1
BEGIN
IF #nested = 0 ROLLBACK
RETURN 1
END
ELSE
BEGIN
IF #nested = 0 COMMIT
END
PRINT ##TRANCOUNT
RETURN 0
END
GO
The outer procedure checks the success/fail an rolls back the transaction if appropriate.
CREATE PROCEDURE dbo.sp1
#trip BIT
AS
BEGIN
DECLARE #result INT
SET NOCOUNT, XACT_ABORT ON
BEGIN TRAN
PRINT ##TRANCOUNT
BEGIN TRY
EXEC #result = dbo.sp2 #trip = #trip, #nested = 1
IF #result <> 0
BEGIN
ROLLBACK
RETURN 1
END
END TRY
BEGIN CATCH
PRINT ERROR_MESSAGE()
END CATCH
PRINT ##TRANCOUNT
COMMIT
PRINT ##TRANCOUNT
RETURN 0
END
GO
Every stored procedure must end with the same transaction count with which it entered. If the count does not match, SQL Server will issue error 266, "Transaction count after EXECUTE indicates that a COMMIT or ROLLBACK TRANSACTION statement is missing."
If a stored procedure does not initiate the outermost transaction, it should not issue a ROLLBACK.
If a nested procedure begin a new transaction; but if it detects the need to roll back and the ##TRANSACTION value is greater than 1, it raises an error, returns an error message to the caller via out parameter or return value, and issues a COMMIT instead of a ROLLBACK.
CREATE PROCEDURE [dbo].[Pinner]
-- Add the parameters for the stored procedure here
#ErrorMessage varchar(max) out
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
-- Insert statements for procedure here
begin tran
begin try
throw 51000, 'error occured', 1
commit tran
set #ErrorMessage = ''
end try
begin catch
set #ErrorMessage = ERROR_MESSAGE();
if ##TRANCOUNT = 1
rollback tran
if ##TRANCOUNT > 1
commit tran
end catch
END
create PROCEDURE [dbo].[Pouter]
-- Add the parameters for the stored procedure here
#ErrorMessage varchar(max) out
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
-- Insert statements for procedure here
begin tran
begin try
EXECUTE [dbo].[Pinner]
#ErrorMessage OUTPUT
if #ErrorMessage <> '' begin
throw 51000, #ErrorMessage, 1
end
commit tran
set #ErrorMessage = ''
end try
begin catch
set #ErrorMessage = ERROR_MESSAGE();
if ##TRANCOUNT = 1
rollback tran
if ##TRANCOUNT > 1
commit tran
end catch
END
DECLARE #ErrorMessage varchar(max)
EXEC [dbo].[Pouter]
#ErrorMessage = #ErrorMessage OUTPUT
SELECT #ErrorMessage as N'#ErrorMessage'
https://www.codemag.com/article/0305111/handling-sql-server-errors-in-nested-procedures
USE [DemoProject]
GO
/****** Object: StoredProcedure [dbo].[Customers_CRUD] Script Date: 11-Jan-17 2:57:38 PM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE [dbo].[Customers_CRUD]
#Action VARCHAR(10)
,#BId INT = NULL
,#Username VARCHAR(50) = NULL
,#Provincename VARCHAR(50) = NULL
,#Cityname VARCHAR(50) = NULL
,#Number VARCHAR(50) = NULL
,#Name VARCHAR(50) = NULL
,#ContentType VARCHAR(50) = NULL
,#Data VARBINARY(MAX) = NULL
AS
BEGIN
SET NOCOUNT ON;
--SELECT
IF #Action = 'SELECT'
BEGIN
SELECT BId , Username,Provincename,Cityname,Number,Name,ContentType, Data
FROM tblbooking
END
--INSERT
IF #Action = 'INSERT'
BEGIN
INSERT INTO tblbooking(Username,Provincename,Cityname,Number,Name,ContentType, Data)
VALUES (#Username ,#Provincename ,#Cityname ,#Number ,#Name ,#ContentType ,#Data)
END
--UPDATE
IF #Action = 'UPDATE'
BEGIN
UPDATE tblbooking
SET Username = #Username,Provincename = #Provincename,Cityname = #Cityname,Number = #Number,Name = #Name,ContentType = #ContentType,Data = #Data
WHERE BId = #BId
END
--DELETE
IF #Action = 'DELETE'
BEGIN
DELETE FROM tblbooking
WHERE BId = #BId
END
END
GO

How can I see errors from a MySQL stored procedure?

With regards to using MySQL stored procedures with transactions, and I am having a problem getting error output.
The problem is that I need to set an exit_handler to roll back the transaction if anything fails. But when I do this, I don't get any error output if something goes wrong. For example if I accidentally pass a NULL value and try to insert it into a non-null field.
I am using a return value to programmatically indicate success or failure, however this does nothing to tell me what actually went wrong.
I am using Perl DBI to talk to MySQL. I am using MySQL 5.0.92 on the production server and MySQL 5.0.51a on the development server. Upgrading to a newer version of MySQL is politically untenable.
This is a simplified example:
DELIMITER //
CREATE PROCEDURE pmt_new(
app_id varchar(40),
out ret tinyint unsigned,
out pmt_req_id int(10) unsigned)
BEGIN
DECLARE v_pmt_req_type int(10) unsigned;
DECLARE exit handler for not found, sqlwarning, sqlexception rollback;
set ret=1;
START TRANSACTION;
SELECT pmt_type INTO v_pmt_req_type FROM pmt_req_types WHERE pmt_req_name = 'Name 1';
INSERT INTO pmt_reqs (pmt_req_id, pmt_req_type, app_id)
values (null, v_pmt_req_type, app_id);
set pmt_req_id = last_insert_id();
INSERT INTO other (pmt_req_id) values (pmt_req_id);
COMMIT;
set ret=0;
END//
DELIMITER ;
Instead of just doing a rollback in your exit handler you need to return something as well...
You currently have
DECLARE exit handler for not found, sqlwarning, sqlexception rollback;
Change it to something like...
DECLARE exit handler for not found, sqlwarning, sqlexception
begin
rollback;
select "We had to rollback, error!";
end;
In 5.5 they added the SIGNAL/RESIGNAL statements so you could 'return' an error but prior versions you have to kind of roll your own solution. If you need you can declare multiple exit handlers to tailor the output better, or setup your own error table you can pull from.
You can also do input testing inside your stored procedure. Want to know if app_id is null?
DELIMITER //
CREATE PROCEDURE pmt_new(
app_id varchar(40),
out result varchar(256),
out ret tinyint unsigned,
out pmt_req_id int(10) unsigned)
BEGIN
DECLARE v_pmt_req_type int(10) unsigned;
DECLARE exit handler for not found, sqlwarning, sqlexception rollback;
SET ret=1;
SET result = "";
IF app_id IS NULL THEN
set result = "Supplied ID is Null";
ELSE
START TRANSACTION;
SELECT pmt_type INTO v_pmt_req_type FROM pmt_req_types WHERE pmt_req_name = 'Name 1';
INSERT INTO pmt_reqs (pmt_req_id, pmt_req_type, app_id)
values (null, v_pmt_req_type, app_id);
set pmt_req_id = last_insert_id();
INSERT INTO other (pmt_req_id) values (pmt_req_id);
COMMIT;
set ret=0;
END IF;
END//
DELIMITER ;
Doing it this way adds another out parameter, but gives you much better information. You could do the same with multiple exit handlers.

How to commit and rollback transaction in sql server?

I have a huge script for creating tables and porting data from one server. So this sceipt basically has -
Create statements for tables.
Insert for porting the data to these newly created tables.
Create statements for stored procedures.
So I have this code but it does not work basically ##ERROR is always zero I think..
BEGIN TRANSACTION
--CREATES
--INSERTS
--STORED PROCEDURES CREATES
-- ON ERROR ROLLBACK ELSE COMMIT THE TRANSACTION
IF ##ERROR != 0
BEGIN
PRINT ##ERROR
PRINT 'ERROR IN SCRIPT'
ROLLBACK TRANSACTION
RETURN
END
ELSE
BEGIN
COMMIT TRANSACTION
PRINT 'COMMITTED SUCCESSFULLY'
END
GO
Can anyone help me write a transaction which will basically rollback on error and commit if everything is fine..Can I use RaiseError somehow here..
Don't use ##ERROR, use BEGIN TRY/BEGIN CATCH instead. See this article: Exception handling and nested transactions for a sample procedure:
create procedure [usp_my_procedure_name]
as
begin
set nocount on;
declare #trancount int;
set #trancount = ##trancount;
begin try
if #trancount = 0
begin transaction
else
save transaction usp_my_procedure_name;
-- Do the actual work here
lbexit:
if #trancount = 0
commit;
end try
begin catch
declare #error int, #message varchar(4000), #xstate int;
select #error = ERROR_NUMBER(), #message = ERROR_MESSAGE(), #xstate = XACT_STATE();
if #xstate = -1
rollback;
if #xstate = 1 and #trancount = 0
rollback
if #xstate = 1 and #trancount > 0
rollback transaction usp_my_procedure_name;
raiserror ('usp_my_procedure_name: %d: %s', 16, 1, #error, #message) ;
return;
end catch
end
As per http://msdn.microsoft.com/en-us/library/ms188790.aspx
##ERROR: Returns the error number for the last Transact-SQL statement executed.
You will have to check after each statement in order to perform the rollback and return.
Commit can be at the end.
HTH
Avoid direct references to '##ERROR'.
It's a flighty little thing that can be lost.
Declare #ErrorCode int;
... perform stuff ...
Set #ErrorCode = ##ERROR;
... other stuff ...
if #ErrorCode ......