October 15, 2013 at 1:11 pm
I overheard our DBA today (2013-10-17) telling a junior developer to NEVER use a TRY-CATCH block in stored procedures. He told her that it is a very inefficient way of creating a transaction and should not be used. He said it was only still available for "backward compatibility." Instead, he suggested she put a BEGIN TRANSACTION and COMMIT or ROLLBACK TRANSACTION around anything that would do an insert or update.
To my knowledge, TRY-CATCH was introduced in SQL 2005. I've been using it regularly as a best practice since about 2007, and this is the first time I've ever heard anyone say it should not be used.
Any opinions here? Is a TRY-CATCH block still a valid practice today?
(Part of the reason I'm obsessing over this is because he is pretty full of himself and also made the statement, "Trust me, I've been doing this for 10 years," to support his argument. That kind of statement drives me nuts.)
Thanks!
edit: took out the stupid and invalid "END TRANSACTION" statement. (LJ)
October 15, 2013 at 1:18 pm
Larry Johnson-473989 (10/15/2013)
I overheard our DBA today (2013-10-17) telling a junior developer to NEVER use a TRY-CATCH block in stored procedures. He told her that it is a very inefficient way of creating a transaction and should not be used. He said it was only still available for "backward compatibility." Instead, he suggested she put a BEGIN TRANSACTION and END TRANSACTION around anything that would do an insert or update.To my knowledge, TRY-CATCH was introduced in SQL 2005. I've been using it regularly as a best practice since about 2007, and this is the first time I've ever heard anyone say it should not be used.
Any opinions here? Is a TRY-CATCH block still a valid practice today?
(Part of the reason I'm obsessing over this is because he is pretty full of himself and also made the statement, "Trust me, I've been doing this for 10 years," to support his argument. That kind of statement drives me nuts.)
Thanks!
If you got your quote correct that person is moron. TRY-CATCH is not used to create transactions. It is used as a way to handle errors. It is not deprecated so the discussion about it being for backwards compatibility is completely ridiculous.
Here is the page in BOL. http://technet.microsoft.com/en-us/library/ms175976.aspx
Next I am guessing this person will tell them to use "nested transactions" when there are a series of inserts that all need to work.
_______________________________________________________________
Need help? Help us help you.
Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.
Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.
Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/
October 15, 2013 at 1:24 pm
Larry Johnson-473989 (10/15/2013)
I overheard our DBA today (2013-10-17) telling a junior developer to NEVER use a TRY-CATCH block in stored procedures. He told her that it is a very inefficient way of creating a transaction and should not be used. He said it was only still available for "backward compatibility." Instead, he suggested she put a BEGIN TRANSACTION and END TRANSACTION around anything that would do an insert or update.To my knowledge, TRY-CATCH was introduced in SQL 2005. I've been using it regularly as a best practice since about 2007, and this is the first time I've ever heard anyone say it should not be used.
Any opinions here? Is a TRY-CATCH block still a valid practice today?
(Part of the reason I'm obsessing over this is because he is pretty full of himself and also made the statement, "Trust me, I've been doing this for 10 years," to support his argument. That kind of statement drives me nuts.)
Thanks!
Wut?
Keep that man away from databases!
Next he'll tell you to rewrite your code to use cursors.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
October 15, 2013 at 1:26 pm
Larry Johnson-473989 (10/15/2013)
I overheard our DBA today (2013-10-17) telling a junior developer to NEVER use a TRY-CATCH block in stored procedures. He told her that it is a very inefficient way of creating a transaction and should not be used. He said it was only still available for "backward compatibility." Instead, he suggested she put a BEGIN TRANSACTION and END TRANSACTION around anything that would do an insert or update.
Wow, that's ... interesting.
Try ... catch doesn't create a transaction at all (trivial to prove) and hence begin transaction cannot be considered a credible alternative to try..catch
Try .. catch is most certainly not deprecated (ie included only for backward compatibility) and it is in fact newer than begin transcation.
END TRANSACTION is not valid T-SQL.
BEGIN TRANSACTION
DELETE FROM a
END TRANSACTION
Msg 156, Level 15, State 1, Line 4
Incorrect syntax near the keyword 'TRANSACTION'.
Try.. Catch is for error handling, much like in front end languages. It does not create, roll back or commit transactions.
BEGIN TRANSACTION... ROLLBACK/COMMIT TRANSACTION is for transaction management, for making a group of data modifications execute atomically. It does not do error handling.
In short, he might as well have said 'Trains are outdated, don't use them. I recommend using a microwave oven instead"
Perhaps of interest: http://sqlinthewild.co.za/index.php/2011/05/17/on-transactions-errors-and-rollbacks/
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
October 15, 2013 at 1:27 pm
Thanks, Sean. I also looked through that article prior to posting my question, and I couldn't find anything to support his assertions. I thought: What am I missing here?
So now I need to come up with a strategy to convince him otherwise...
October 15, 2013 at 1:29 pm
@Gail: Oops, my bad on the "END TRANSACTION". I was just so pissed that he was bad-mouthing me behind my back to the junior developer (because I'm the one who told her to use transactions) that I was typing before thinking...
October 15, 2013 at 1:31 pm
One retort. If he insists that TRY..CATCH is an 'inefficient way of starting a transaction', then you could start by proving to him that it doesn't start a transaction at all.
Maybe offer him that blog post? Though if he's as set in his ways as you make out, he may refuse to read someone else's 'ignorant opinion' (as I've had my work described before 🙂 )
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
October 15, 2013 at 2:22 pm
Well, your DBA is absolutely right "that it (a TRY-CATCH block) is a very inefficient way of creating a transaction". 🙂
I also agree, that it therefore should not be used for transactional mananagement.
But for totally different reasons than he does, as already explained.
Maybe you can get him into a discussion by agree to a part of his statement first (to polish his halo) followed by "the bad news"...
Another option would be to ask him for a more detailed explanation and some sample code so you can "widen your view" and learn from his "10 year experience".
October 15, 2013 at 3:07 pm
Thank you everyone for your feedback!
-LJ
October 15, 2013 at 6:33 pm
Sean Lange (10/15/2013)
If you got your quote correct that person is moron.
Heh... if the quote is correct, then that "DBA" is more off than on, so stop insulting morons. He's clearly a moroff. 😀
The one thing that I do agree with is...
... if there are no special error messages required and
... if all you're going to do in the CATCH block is rethrow the same error and
... if you don't need redirection of special handling on an error
... then there's usually no need for Try/Catch blocks in a stored procedure. Let SQL Server do what it was designed to do. If you need multiple commands in a stored procedure to act as an "all or nothing" unit, the using explicit transactions with SET XACT_ABORT ON is usually enough for a lot of people.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 15, 2013 at 6:58 pm
Larry Johnson-473989 (10/15/2013)
(Part of the reason I'm obsessing over this is because he is pretty full of himself and also made the statement, "Trust me, I've been doing this for 10 years," to support his argument. That kind of statement drives me nuts.)
Lordy! I agree! I hate such arrogant ring-knocking even if they happen to be qualified to make such a brag. People truly worth their salt won't make such a brag as a replacement for proof and will embrace the opportunity to mentor someone about the "why" instead of that "trust me" line of hooie. Sounds more like he was trying to impress the opposite sex than do anything DBA-like.
If I have to work with someone like this, I'll normally try to thoughtfully and kindly coach them into not saying such things and into being a more informed and bettor mentor. I do have an extremely low tolerance for such malarky though. It's a "porkchop-able" offense.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 15, 2013 at 7:01 pm
Larry Johnson-473989 ([font="Arial Black"]10/15/2013[/font])
I overheard our DBA today ([font="Arial Black"]2013-10-17[/font])...
Heh... unless you happen to be a master with DBCC TIMEWARP, that's gotta be a phat phinger. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
October 15, 2013 at 7:45 pm
TRY/CATCH statements are used to rollback a transaction if an error occurs in processing. The COMMIT goes at the end of the TRY and the ROLLBACK goes inside the CATCH. Without them, the transaction is left open if an error occurs during processing. This open transaction will continue to hold all the locks it established until the the connection is disconnected, the transaction is rolled back manually, or the process becomes a deadlock victim. In the case of a long running process that doesn't have a command timeout, that's essentially forever - at least until the 'all knowing' DBA terminates 'mysterious hung processes' as part of his daily routine.
October 15, 2013 at 9:04 pm
lnardozi 61862 (10/15/2013)
Without them, the transaction is left open if an error occurs during processing.
Unless XACT_ABORT is on.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
October 15, 2013 at 9:07 pm
Sean Lange (10/15/2013)
If you got your quote correct that person is moron.
Well now Sean, there was no reason to hold back because we're all friends here. Why don't you tell us what you really think? 😛
I 100% agree with this and what Jeff said above also.
If I were to offer a pet-peeve, using TRY-CATCH needs to be done properly. That is, checking for XACT_STATE() and then rolling back the TRANSACTION in a properly prescribed fashion. It is particularly useful in SQL Agent run SPs that need to report when things go awry because there's no front end to handle the resulting failure.
My thought question: Have you ever been told that your query runs too fast?
My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.
Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
Since random numbers are too important to be left to chance, let's generate some![/url]
Learn to understand recursive CTEs by example.[/url]
[url url=http://www.sqlservercentral.com/articles/St
Viewing 15 posts - 1 through 15 (of 19 total)
You must be logged in to reply to this topic. Login to reply