Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Erland Sommarskog Newsgroups: comp.databases.ms-sqlserver,microsoft.public.sqlserver.programming Subject: Re: SSE 2008: Transactions and Rollbacks: When are they done? Date: Wed, 18 May 2011 23:39:09 +0200 Organization: Erland Sommarskog Lines: 62 Message-ID: References: <91q5t6h56vk3db1ipt8eacd5407jc08c7f@4ax.com> <9618t6ta7j80ptb76ko10h873g28v5dsmf@4ax.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Injection-Info: mx04.eternal-september.org; posting-host="DD6dU+BfJNjsjSP4/K/V7w"; logging-data="9050"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19vuRnIZ5CkkE/LoWjr2g85" User-Agent: Xnews/2006.08.24 Mime-proxy/2.1.c.0 (Win32) Cancel-Lock: sha1:naYnVHYfrgQ/jU3HY0q5PMs6dUM= Xref: x330-a1.tempe.blueboxinc.net comp.databases.ms-sqlserver:353 Gene Wirchenko (genew@ocis.net) writes: > Had I not been checking trigger code, there would not have been > an implicit transaction created, and it would have been correct (and a > good idea) to have a BEGIN TRANSACTION. Since the code in question is > a trigger, there is no need for a BEGIN TRANSACTION, but it does not > hurt. Actually, I recommend against using BEGIN and COMMIT TRANSACTION in triggers; only ROLLBACK makes sense. > In the trigger, because a raiserror() caused the catch block to > be executed, a rollback will automatically occur. This is getting confusing even for me! You see, normally RAISERROR does not terminate the batch, even if XACT_ABORT is on. But yes, in a trigger. This is probably for compatibility reasons. > Were it not trigger code, then the setting of SET XACT_ABORT > would matter. Actually, XACT_ABORT matters also in triggers. It is just that the default is different. > Does the setting for SET XACT_ABORT get restored when a trigger > finishes execution? Yes. The effect of any SET command is reverted when the scope in which the SET command was executed in exists. (With one single exception SET CONTEXT_INFO.) > How does this work when there are other > procedures called? Same question, but is it any different if the > lower-level procedure raises an error (as does your error handler)? XACT_ABORT ON extends into these procedures, and errors in the procedures will bubble up to the trigger. There is however a completely horrendeous exception. Normally if you something like: CREATE PROCEDURE bad_tran AS BEGIN TRANSACTION You will get an error about trancount mismatch. But if the procedure is called from a trigger, the error is suppressed. I reported this as a bug - it was closed by design! (And I think I've seen it documented in Books Online.) > Nothing that I have read has mentioned when to set SET > XACT_ABORT. Is any time before an error occurs acceptable? From your > last paragraph, the answer to this appears to be yes. > > Correct? Many people put SET NOCOUNT ON in the top of their procedures. That could be a good place for SET XACT_ABORT ON as well. -- Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se Links for SQL Server Books Online: SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx