Do stored procedures need transactions?

If I want everything in a stored procedure to roll back if any part fails, does it need begin/commit transaction?

Also, if I insert into tableM and just after need the indentity value from that insert, is @@IDENTITY the correct way to get it?  @@IDENTITY will get the last indentity value on any connection so I'm not sure about using it.  But does being in a sproc or transaction make a different?
Who is Participating?
AlokJain0412Connect With a Mentor Commented:
Dear this is the perfect statndard exmple of tansaction and error handling ,

1. @error return the error no of last transaction
and @error =0 means no error
2. If @@TRANCOUNT has a different value when a stored procedure finishes than it had when the procedure was executed, an informational error (266) occurs. This can happen in two ways:

A stored procedure is called with an @@TRANCOUNT of 1 or greater and the stored procedure executes a ROLLBACK TRANSACTION statement. @@TRANCOUNT decrements to 0 and causes an error 266 when the stored procedure completes.

A stored procedure is called with an @@TRANCOUNT of 1 or greater and the stored procedure executes a COMMIT TRANSACTION statement. @@TRANCOUNT decrements by 1 and causes an error 266 when the stored procedure completes. However, if BEGIN TRANSACTION is executed after the COMMIT TRANSACTION, the error does not occur.


Using TRY...CATCH to Rollback a Transaction in the Face of an Error

    As you saw in earlier example, one of the downsides of the @@ERROR variable approach is that to implement Transaction; we must check this variable after each and every DML SQL statement to determine if an error occurred and, if so, to rollback the transaction. With SQL Server 2005's TRY...CATCH block, however, these types of scripts are greatly simplified.
    Lets Alter the Previous Example!

ALTER PROC usp_AccountTransaction

@AccountNum INT,




BEGIN TRY --Start the Try Block..

BEGIN TRANSACTION -- Start the transaction..

UPDATE MyChecking SET Amount = Amount - @Amount

WHERE AccountNum = @AccountNum

UPDATE MySavings SET Amount = Amount + @Amount

WHERE AccountNum = @AccountNum

COMMIT TRAN -- Transaction Success!




ROLLBACK TRAN --RollBack in case of Error

-- you can Raise ERROR with RAISEERROR() Statement including the details of the exception





    Just look at the simplicity and line of code than previous example!

    In the TRY block a transaction is started and the two UPDATE statements are performed. If both UPDATEs succeed, the COMMIT will be reached and the transaction committed. If, however, either one produces an error, control will be execute CATCH block where the transaction will be rolled back.

    Also, you can “re-raises” the error (using RAISERROR) so that the error information will be passed up to your .Net application from where you are calling the Stored Procedure, in case if you want to use the error information to process further steps anyhow.

    Thats it. lets Code Better!
Ephraim WangoyaConnect With a Mentor Commented:

Yes, you need to use transaction begin/commit/rollback

@@IDENTITY will function the same way in a stored procedure
DBAduck - Ben MillerConnect With a Mentor Principal ConsultantCommented:
Just a note that I would not use @@IDENTITY as it has some Scoping problems like for triggers, etc.

Use SCOPE_IDENTITY() directly after the statement, or if you want to eliminate all scoping problems, just look up the OUTPUT clause for Inserts in BOL.
Yes begin tran

For better undersstanding  of Idendtity value
 (@@IDENTITY vs SCOPE_IDENTITY())  You can better understand with refer Link 
brettrAuthor Commented:

What is the best way to rollback?  I've seen several techniques.  Most just look for an error code and put the rollback in a conditional.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.