August 5, 2013 at 9:09 am
Hi,
I have a Database created before SQL Server 2005. It contains many table Triggers with RAISEERROR statements like:
RAISERROR 44446 'The record can''t be added or changed. Referential integrity rules require a related record in table ''tblPolicy''.'
SQL Server 2012 tells me this has a syntax error, and Books Online provides the correct syntax as:
RAISERROR ('The record can''t be added or changed. Referential integrity rules require a related record in table ''tblPolicy''.', 0, 1)
Is there any way to make the old syntax work in SQL Server 2012 as it does in SQL Server 2005?
Thanks
Norm
August 5, 2013 at 9:53 am
normturgeon (8/5/2013)RAISERROR 44446 'The record can''t be added or changed. Referential integrity rules require a related record in table ''tblPolicy''.'
I'm working with SQL Server since SQL 2000. I did not even know that this syntax works at all. I only know the raiserror( Message, Severity, State) syntax.
August 5, 2013 at 10:53 am
Set the database compatibility level back to 90
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
August 5, 2013 at 3:38 pm
No, that old syntax for RAISERROR (which has been deprecated since SQL 6.0 released) does not work in SQL 2012 in any compatibility mode.
Ironically, SQL 2012 includes a new command ;THROW which uses almost the same syntax as the old RAISERROR syntax. (There is a third mandatory parameter for state.)
[font="Times New Roman"]Erland Sommarskog, SQL Server MVP, www.sommarskog.se[/font]
August 5, 2013 at 11:57 pm
Erland Sommarskog (8/5/2013)
No, that old syntax for RAISERROR (which has been deprecated since SQL 6.0 released) does not work in SQL 2012 in any compatibility mode.Ironically, SQL 2012 includes a new command ;THROW which uses almost the same syntax as the old RAISERROR syntax. (There is a third mandatory parameter for state.)
I'm not sure what the irony is here. But note that BOL suggests using THROW rather than RAISERROR for applications built in 2012 and onwards.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
August 6, 2013 at 1:11 am
Phil Parkin (8/5/2013)
[bBut note that BOL suggests using THROW rather than RAISERROR for applications built in 2012 and onwards.
Microsoft are keen on recommending on what they happened to come most recently. Note that ;THROW works somewhat differently from RAISERROR, which can trip you if you change your code blindly.
Error handling in SQL Server is a big big big mess. And they only made that mess bigger in SQL 2012 with adding ;THROW to the mix. Previously, you could rely on that if the batch was aborted, your transaction was rolled back, but this is no longer true. Casual use of ;THROW can result in orphaned transactions, so be careful!
[font="Times New Roman"]Erland Sommarskog, SQL Server MVP, www.sommarskog.se[/font]
August 6, 2013 at 5:48 am
Erland Sommarskog (8/6/2013)
Previously, you could rely on that if the batch was aborted, your transaction was rolled back
Really? As far as I know the standard behavior is that an exception does not influencde the transaction. You raise an exception, any currently open transaction remains open and the code continues.
There are some errors that cause a tranaction to be rolled back, e.g. selecting a non existing table
There are some SET options too (ANSI_WARNINGS, ARITHABORT, XACT_ABORT) to influence the behaviour. I guess you use one or more options as a standard for having transactions rolled back on an error.
Of course Microsoft tells us to use THROW instead of RAISERROR. They alwalys do when introducing a new command and marking the "old" command as deprecated. The want you to give enough time to change all your production code until the old command is REALLY deprecated some time.
August 6, 2013 at 6:05 am
WolfgangE (8/6/2013)
Really? As far as I know the standard behavior is that an exception does not influencde the transaction. You raise an exception, any currently open transaction remains open and the code continues.
I said if. As you say, there are errors that only terminate the current statement and where execution continues with the next statement, and no transaction is rolled back.
There are some errors that cause a tranaction to be rolled back, e.g. selecting a non existing table
That error aborts the current scope, and does not roll back the transaction (unless XACT_ABORT is ON). That's also bad.
Of course Microsoft tells us to use THROW instead of RAISERROR. They alwalys do when introducing a new command and marking the "old" command as deprecated.
Note that RAISERROR is not deprecated. There are things you can do with RAISERROR that you cannot do with ;THROW. (WITH NOWAIT, WITH NOLOG, set severity level.)
[font="Times New Roman"]Erland Sommarskog, SQL Server MVP, www.sommarskog.se[/font]
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply