April 2, 2012 at 11:44 pm
Comments posted to this topic are about the item Bye Bye to the RAISERROR Function?
April 3, 2012 at 1:30 am
informative information. thx
Thanks
Vinay Kumar
-----------------------------------------------------------------
Keep Learning - Keep Growing !!!
April 3, 2012 at 5:22 am
By default, the Throw statement always has the severity of 16.
Microsoft deprecates yet another incredibly useful tool and replaces it with a piece of garbage with much fewer capabilities.
The "advantages" you have for THROW are actually disadvantages for me especially when it comes to THROW having fewer parameters. I really hope this is April Fools joke. I'm totally disgusted with what Microsoft thinks "improvements" actually are.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 3, 2012 at 6:23 am
Jeff Moden (4/3/2012)
By default, the Throw statement always has the severity of 16.
Microsoft deprecates yet another incredibly useful tool and replaces it with a piece of garbage with much fewer capabilities.
The "advantages" you have for THROW are actually disadvantages for me especially when it comes to THROW having fewer parameters. I really hope this is April Fools joke. I'm totally disgusted with what Microsoft thinks "improvements" actually are.
Recommending it in SQL 2012 means we have it for at least 3 more releases... I don't know about you, but SQL 2020 sounds like a long time from now. 😛 😛 😛
And of course, if there is enough complaining, Microsoft will fix THROW's short comings.
April 3, 2012 at 8:43 am
actually, Microsoft has not stated that RAISERROR is deprecated at all. It is still a valid command.
what is ACTUALLY not possible in SQL 2012 is using RAISERROR like this;
RAISERROR 50001 'this is a test'
in which case THROW would be the only choice.
the code RAISERROR 50001 'this is a test'
will work in SQL 2008 R2 and lower however, THROW will not. (because it does not exist)
please correct your article to show this as it may cause FUD as it did with me.....
April 3, 2012 at 9:33 am
Jeff Moden (4/3/2012)
The "advantages" you have for THROW are actually disadvantages for me especially when it comes to THROW having fewer parameters. I really hope this is April Fools joke. I'm totally disgusted with what Microsoft thinks "improvements" actually are.
And here I thought it was a better move. RAISERROR can depend on sys.messages, which creates a dependency for the database on the instance. This can easily cause issues in DR situations, or database moves. The idea of getting more contained inside databases means we need a better way. I suppose RAISERROR could have been modified to use a database table, but I'm not sure THROW is a bad move.
It probably needs a little more work, and I'd encourage you to submit ideas to CONNECT and get people to vote for them. I think THROW will work well in the future.
April 3, 2012 at 11:32 am
Steve Jones - SSC Editor (4/3/2012)
Jeff Moden (4/3/2012)
The "advantages" you have for THROW are actually disadvantages for me especially when it comes to THROW having fewer parameters. I really hope this is April Fools joke. I'm totally disgusted with what Microsoft thinks "improvements" actually are.
And here I thought it was a better move. RAISERROR can depend on sys.messages, which creates a dependency for the database on the instance. This can easily cause issues in DR situations, or database moves. The idea of getting more contained inside databases means we need a better way. I suppose RAISERROR could have been modified to use a database table, but I'm not sure THROW is a bad move.
It probably needs a little more work, and I'd encourage you to submit ideas to CONNECT and get people to vote for them. I think THROW will work well in the future.
Adding THROW is a great idea. Removing RAISERROR is a horrible idea. I'm going to write an article on how to use RAISERROR the way I use it, show that it can't be done with THROW, and open a CONNECT item pointing to the article.
From where I sit, THROW needs a hell of a lot of work to even come close to the easy functionality you can get out of RAISERROR. Does RAISERROR have some problems? You bet. And they should fix those problems instead of removing still more functionality. Considering all the things that THROW cannot do, I'm 100% sure that I'll never use it. Heh... same goes for FORMATMESSAGE. Way too much work and employs the very same technology/requirements that so many say you have to do with RAISERROR to make it useful and nothing could be further from the truth there.
--Jeff Moden
Change is inevitable... Change for the better is not.
April 3, 2012 at 11:43 am
RAISERROR is not being removed!!!
the only functionallity that has changed it you cannot pass RAISERROR less the ()
you use to be able to send RAISERROR 50000 'this is a test'
without the ()
in SQL 2012, if you want to use RAISERROR 50000 'this is a test'
it will fail. but in SQL 2012 you can still use RAISERROR ('this is a test',16,1)
or in SQL 2012, you can just use THROW.
all other forms of RAISERROR still work as always in SQL 2012 and Microsoft clearly states this on the links at the front of the article.
other usefull info is located here;
April 3, 2012 at 5:47 pm
Thanks for the "warm fuzzies" and facts on the plight (or lack of, I should say) of RAISERROR especially considering the name of this article. I finally had the time to go check the deprecation list for 2k12 and I'm very happy to see that it's not on there except for the () problem.
I'm still going to write an article about RAISERROR and some of the nifty things you can do with it without getting into sys. Messages. I just don't trust MS much when they say things in their official BOL documentation like "New applications should use THROW instead" ( http://msdn.microsoft.com/en-us/library/ms178592.aspx )regardless of context. They said similar about sp_MakeWebTask way back in 2k when SSRS was nothing but an addon. If no one has already done it, I'll still open a CONNECT item to suggest that they really need to add some functionality like being able to supply an optional severity level, etc. :Whistling:
--Jeff Moden
Change is inevitable... Change for the better is not.
April 3, 2012 at 7:32 pm
Yeah, when I wrote the article the BOL said, that they were going to remove it in future releases. It seems that they changed their minds and updated the BOL.
RAISERROR is nice, but MS had some problems with it and the try catch clauses and severities. If you are using them and you have sql 2k12, you should use the Throw instead.
April 9, 2012 at 11:32 pm
Jeff Moden - your correct, one of the most important things that RAISEERROR gives you is the ability to log to the application log, which lets you monitor from outside for problems that occurred on different processes, the new alternative of THROW is pale.
April 22, 2012 at 10:24 am
calbimonte.daniel (4/3/2012)
RAISERROR is nice, but MS had some problems with it and the try catch clauses and severities. If you are using them and you have sql 2k12, you should use the Throw instead.
Gosh... I wouldn't make a blanket recommendation like that. THROW doesn't have half the functionality of RAISERROR. I also have NOT had the problems you speak of when using it with "TRY/CATCH clause and severities". A better recommendation might be to learn how to properly use RAISERROR properly. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply