Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

RAISEERROR syntax Expand / Collapse
Author
Message
Posted Monday, August 5, 2013 9:09 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, June 6, 2014 5:21 AM
Points: 7, 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
Post #1480960
Posted Monday, August 5, 2013 9:53 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, December 19, 2014 4:36 AM
Points: 199, Visits: 740
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.
Post #1480980
Posted Monday, August 5, 2013 10:53 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 3:41 PM
Points: 6,760, Visits: 14,413
Set the database compatibility level back to 90

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

"Ya can't make an omelette without breaking just a few eggs"
Post #1481008
Posted Monday, August 5, 2013 3:38 PM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Friday, December 12, 2014 1:02 AM
Points: 823, Visits: 753
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
Post #1481105
Posted Monday, August 5, 2013 11:57 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 12:24 AM
Points: 5,317, Visits: 12,355
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.

When you ask a question (and please do ask a question: "My T-SQL does not work" just doesn't cut it), please provide enough information for us to understand its context.

It is better to keep your mouth shut and appear stupid than to open it and remove all doubt. (Mark Twain)
Post #1481162
Posted Tuesday, August 6, 2013 1:11 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Friday, December 12, 2014 1:02 AM
Points: 823, Visits: 753
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
Post #1481180
Posted Tuesday, August 6, 2013 5:48 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, December 19, 2014 4:36 AM
Points: 199, Visits: 740
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.
Post #1481253
Posted Tuesday, August 6, 2013 6:05 AM


SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Friday, December 12, 2014 1:02 AM
Points: 823, Visits: 753
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
Post #1481267
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse