views:

29

answers:

2

I'm working on a large SQL Server codebase, some of which has been in development since at least SQL 7 and possibly before.

Throughout the codebase, the method of raising an error is to use the following syntax which is, as far as I can tell, undocumented

RAISERROR <error number> <error message>

The error number can be any value greater than 13000; no corresponding entry needs to exist in the sys.messages table. The error message can also be arbitrary.

The following sample code

raiserror 13000 'test error'

produces the following output

Msg 13000, Level 16, State 1, Line 1
test error

This behaviour is the same in SQL 2000, 2005 and 2008 (I haven't tested 2008 R2).

We're going to attempt to standardise on a supported method, but my question is where this behaviour came from in the first place.

I assume this must once have been documented, supported behaviour, but copies of books online for SQL 7 and before are difficult to find. Does anybody know when this was supported or when it was deprecated, if ever?

Edit To clarify, according to the documentation, the supported RAISERROR syntax is

RAISERROR ( { msg_id | msg_str | @local_variable }
    { ,severity ,state }
    [ ,argument [ ,...n ] ] )
    [ WITH option [ ,...n ] ]

And any user error number which is not defined in sys.messages should be raised with an error message id of 50000

+1  A: 

A user defined error message is actually from 13000 through to 2147483647.

So the behaviour you are describing is correct - you are raising a user defined error.

Barry
Agreed - but the syntax is not documented, and according to the docs, any user error not defined in `sys.messages` should be raised with an error code of 50000
Ed Harper
+1  A: 

This looks like it might be a throwback to SQL Server's origins in Sybase, whose RAISERROR command has syntax similar to what I've described:

http://infocenter.sybase.com/help/topic/com.sybase.help.ase_15.0.commands/html/commands/commands74.htm

EDIT

Whatever its origins, this syntax is listed to be removed in SQL v11 in the SQL 2008 R2 release notes

Ed Harper