InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comThu, 23 May 2013 21:17:23 GMT20http://www.sqlservercentral.com/Forums/Topic1352339-391-1.aspxBased on your original statement - I would recommend not even using an explicit transaction. Since this is an import process and you are wiping the data (truncating) and then reloading from the source - using a transaction around the inserts/updates is not very useful.Now, if you have to return the system to the state it was in before your process started (on an error, of course) - then you would put the truncate statements inside the transaction also, that way when the statement is rolled back the truncate also gets rolled back.Be aware that this type of process can (and probably will) expand your transaction log to a much larger size. It will require the log to be that size to handle all of the transactions - which cannot be marked as reusable space in the transaction log until all of them complete or are rolled back.Sun, 02 Sep 2012 20:00:42 GMTJeffrey Williams 3188http://www.sqlservercentral.com/Forums/Topic1352339-391-1.aspx[quote][b]Sean Lange (8/30/2012)[/b][hr][quote][b]david.holley (8/30/2012)[/b][hr]So basically a single transaction and then check @@Error after each statement as in...BEGIN TRANUPDATEIF @@ERROR <> 0 GOTO ERR_HANDLERDELETEIF @@ERROR <> 0 GOTO ERR_HANDLERDESTROY WORLDIF @@ERROR <> 0 GOTO ERR_HANDLERINSERTIF @@ERROR <> 0 GOTO ERR_HANDLERCOMMIT TRANRETURN 0ERR_HANDLER:KILL KENNYROLLBACK RETURN 1[/quote]That is not the best way to handle this. You should use try/catch instead the older style of constantly checking @@error.[code]BEGIN TRANbegin try UPDATE DELETE DESTROY WORLD INSERT COMMIT TRAN RETURN 0end trybegin catch KILL KENNY ROLLBACK RETURN 1end catch[/code][/quote]Thanks. I also found this article which helped to explain why the sp's that I've created never threw an error back to the ASP.NET frontend when I tested raising an error.http://www.4guysfromrolla.com/webtech/041906-1.shtmlSun, 02 Sep 2012 14:13:28 GMTdavid.holleyhttp://www.sqlservercentral.com/Forums/Topic1352339-391-1.aspx[quote][b]david.holley (8/30/2012)[/b][hr]So basically a single transaction and then check @@Error after each statement as in...BEGIN TRANUPDATEIF @@ERROR <> 0 GOTO ERR_HANDLERDELETEIF @@ERROR <> 0 GOTO ERR_HANDLERDESTROY WORLDIF @@ERROR <> 0 GOTO ERR_HANDLERINSERTIF @@ERROR <> 0 GOTO ERR_HANDLERCOMMIT TRANRETURN 0ERR_HANDLER:KILL KENNYROLLBACK RETURN 1[/quote]That is not the best way to handle this. You should use try/catch instead the older style of constantly checking @@error.[code]BEGIN TRANbegin try UPDATE DELETE DESTROY WORLD INSERT COMMIT TRAN RETURN 0end trybegin catch KILL KENNY ROLLBACK RETURN 1end catch[/code]Thu, 30 Aug 2012 13:20:15 GMTSean Langehttp://www.sqlservercentral.com/Forums/Topic1352339-391-1.aspxSo basically a single transaction and then check @@Error after each statement as in...BEGIN TRANUPDATEIF @@ERROR <> 0 GOTO ERR_HANDLERDELETEIF @@ERROR <> 0 GOTO ERR_HANDLERDESTROY WORLDIF @@ERROR <> 0 GOTO ERR_HANDLERINSERTIF @@ERROR <> 0 GOTO ERR_HANDLERCOMMIT TRANRETURN 0ERR_HANDLER:KILL KENNYROLLBACK RETURN 1Thu, 30 Aug 2012 13:16:07 GMTdavid.holleyhttp://www.sqlservercentral.com/Forums/Topic1352339-391-1.aspxTo add to what Gail is saying not only do they not really exist the appearance of nested transactions can seem to work when everything goes smoothly but will cause you nothing but grief when stuff doesn't go correctly. If a rollback is issued against as "inner" transaction, the "outer" transaction no longer exists and all your logic is going to break all over the place.Nested transactions in sql server are like leprechauns and unicorns...they might be cool if they actually existed but they don't so stop looking for them. :-DThu, 30 Aug 2012 13:06:11 GMTSean Langehttp://www.sqlservercentral.com/Forums/Topic1352339-391-1.aspx[quote][b]david.holley (8/30/2012)[/b][hr]Example 2:BEGIN TRANSACTION 1 DELETE...BEGIN TRANSACTION 2 UPDATE...BEGIN TRANSACTION 3 INSERTCOMIT TRANSACTION 3COMIT TRANSACTION 2COMIT TRANSACTION 1[/quote]Nested transactions don't actually exists, just syntatical sugar that makes you think they do. That's the same as Example 1.Thu, 30 Aug 2012 11:26:41 GMTGilaMonsterhttp://www.sqlservercentral.com/Forums/Topic1352339-391-1.aspxWhen working with a stored procedure that executes several INSERT, UPDATE , DELETE queries, do I structure the sp so that all of them are contained within a single transaction or do I have to struction the sp so that each query statement is contained within its own transaction? The queries are related to an import that I'm doing where existing data is wiped from the target tables and the replaced with data from the import.Example1:BEGIN TRANSACTION 1DELETE...UPDATE...INSERT....COMIIT TRANSACTION 1Example 2:BEGIN TRANSACTION 1 DELETE...BEGIN TRANSACTION 2 UPDATE...BEGIN TRANSACTION 3 INSERTCOMIT TRANSACTION 3COMIT TRANSACTION 2COMIT TRANSACTION 1Thu, 30 Aug 2012 09:58:08 GMTdavid.holley