SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


RAISEERROR syntax


RAISEERROR syntax

Author
Message
normturgeon
normturgeon
SSC Rookie
SSC Rookie (45 reputation)SSC Rookie (45 reputation)SSC Rookie (45 reputation)SSC Rookie (45 reputation)SSC Rookie (45 reputation)SSC Rookie (45 reputation)SSC Rookie (45 reputation)SSC Rookie (45 reputation)

Group: General Forum Members
Points: 45 Visits: 25
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
WolfgangE
WolfgangE
Ten Centuries
Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)

Group: General Forum Members
Points: 1311 Visits: 798
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.
Perry Whittle
Perry Whittle
SSC Guru
SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)SSC Guru (55K reputation)

Group: General Forum Members
Points: 55212 Visits: 17709
Set the database compatibility level back to 90

-----------------------------------------------------------------------------------------------------------

"Ya can't make an omelette without breaking just a few eggs" ;-)
Erland Sommarskog
Erland Sommarskog
SSCertifiable
SSCertifiable (5.4K reputation)SSCertifiable (5.4K reputation)SSCertifiable (5.4K reputation)SSCertifiable (5.4K reputation)SSCertifiable (5.4K reputation)SSCertifiable (5.4K reputation)SSCertifiable (5.4K reputation)SSCertifiable (5.4K reputation)

Group: General Forum Members
Points: 5360 Visits: 875
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.)

Erland Sommarskog, SQL Server MVP, www.sommarskog.se
Phil Parkin
Phil Parkin
SSC Guru
SSC Guru (52K reputation)SSC Guru (52K reputation)SSC Guru (52K reputation)SSC Guru (52K reputation)SSC Guru (52K reputation)SSC Guru (52K reputation)SSC Guru (52K reputation)SSC Guru (52K reputation)

Group: General Forum Members
Points: 52656 Visits: 21194
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.


Help us to help you. For better, quicker and more-focused answers to your questions, consider following the advice in this link.

If the answer to your question can be found with a brief Google search, please perform the search yourself, rather than expecting one of the SSC members to do it for you.

Please surround any code or links you post with the appropriate IFCode formatting tags. It helps readability a lot.
Erland Sommarskog
Erland Sommarskog
SSCertifiable
SSCertifiable (5.4K reputation)SSCertifiable (5.4K reputation)SSCertifiable (5.4K reputation)SSCertifiable (5.4K reputation)SSCertifiable (5.4K reputation)SSCertifiable (5.4K reputation)SSCertifiable (5.4K reputation)SSCertifiable (5.4K reputation)

Group: General Forum Members
Points: 5360 Visits: 875
Phil Parkin (8/5/2013)
[quote][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!

Erland Sommarskog, SQL Server MVP, www.sommarskog.se
WolfgangE
WolfgangE
Ten Centuries
Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)

Group: General Forum Members
Points: 1311 Visits: 798
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.
Erland Sommarskog
Erland Sommarskog
SSCertifiable
SSCertifiable (5.4K reputation)SSCertifiable (5.4K reputation)SSCertifiable (5.4K reputation)SSCertifiable (5.4K reputation)SSCertifiable (5.4K reputation)SSCertifiable (5.4K reputation)SSCertifiable (5.4K reputation)SSCertifiable (5.4K reputation)

Group: General Forum Members
Points: 5360 Visits: 875
WolfgangE (8/6/2013)
[quote]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.)

Erland Sommarskog, SQL Server MVP, www.sommarskog.se
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search