返回用户定义的错误信息并设系统标志，记录发生错误。通过使用 RAISERROR 语句，客户端可以从 sysmessages 表中检索条目，或者使用用户指定的严重度和状态信息动态地生成一条消息。这条消息在定义后就作为服务器错误信息返回给客户端。

语法RAISERROR ( { msg_id | msg_str } { , severity , state }

[ , argument [ ,...n ] ] )

[ WITH option [ ,...n ] ]

参数msg_id

存储于 sys.messages 表中的用户定义的错误信息。用户定义错误信息的错误号应大于 50,000。由特殊消息产生的错误是第 50,000 号。

msg_str

是一条特殊消息，其格式与 C 语言中使用的 PRINTF 格式样式相似。此错误信息最多可包含 400 个字符。如果该信息包含的字符超过 400 个，则只能显示前 397 个并将添加一个省略号以表示该信息已被截断。所有特定消息的标准消息 ID 是 14,000。

msg_str 支持下面的格式：

% [[flag] [width] [precision] [{h | l}]] type

可在 msg_str 中使用的参数包括：

flag

用于确定用户定义的错误信息的间距和对齐的代码。

代码　前缀或对齐　描述

-（减）　左对齐　在给定字段宽度内左对齐结果。

+（加）　+（加）或 -（减）前缀　如果输出值为带符号类型，则在输出值的前面加上加号（+）或减号（-）。

0（零）　零填充　如果宽度的前面有 0，则添加零直到满足最小宽度。若出现 0 和 -，将忽略 0。若使用整型格式（i, u, x, X, o, d）指定 0，则忽略 0。

#（数字）　对 x 或 X 的十六进制类型使用 0x 前缀　当使用 o、x 或 X 格式时，# 标志在任何非零值的前面分别加上 0、0x 或 0X。当 d、i 或 u 的前面有 # 标记时，将忽略该标记。

' '（空格）　空格填充　如果输出值带符号且为正，则在该值前加空格。如果包含在加号（+）标记中，则忽略该标记。　width

定义最小宽度的整数。星号 (*) 允许 precision 确定宽度。

precision

是输出字段最多输出的字符数，或为整数值输出的最小小数位数。星号 (*) 允许 argument 确定精度。

{h | l} type

与字符类型 d、i、o、x、X 或 u 一起使用，用于创建 shortint (h) 或 longint (l) 类型的值。

字符类型　表示

d 或 I　带符号的整数

o　不带符号的八进制数

p　指针型

s　String

u　不带符号的整数

x 或 X　不带符号的十六进制数说明 不支持float、双精度和单精度字符类型。

severity

用户定义的与消息关联的严重级别。用户可以使用从 0 到 18 之间的严重级别。19 到 25 之间的严重级别只能由 sysadmin 固定服务器角色成员使用。若要使用 19 到 25 之间的严重级别，必须选择 WITH LOG 选项。

注意 20 到 25 之间的严重级别被认为是致命的。如果遇到致命的严重级别，客户端连接将在收到消息后终止，并将错误记入错误日志和应用程序日志。

state

从 1 到 127 的任意整数，表示有关错误调用状态的信息。state 的赋值默认为 1。

argument

是用于取代在 msg_str 中定义的变量或取代对应于 msg_id 的消息的参数。可以有 0 或更多的替代参数；然而，替代参数的总数不能超过 20 个。每个替代参数可以是局部变量或这些任意数据类型：int1、int2、int4、char、varchar、binary 或 varbinary。不支持其它数据类型。

option

错误的自定义选项。option 可以是以下值之一：

值　描述

LOG　将错误记入服务器错误日志和应用程序日志。记入服务器错误日志的错误目前被限定为最多 440 字节。

NOWAIT　将消息立即发送给客户端。

SETERROR　将 @@ERROR 的值设置为 msg_id 或 50000，与严重级别无关。　注释 如果使用 sysmessages 错误并且是使用前面显示的 msg_str 格式创建的消息，则将给所提供的 msg_id 的消息传递提供的参数（argument1、argument2 等等）。

当使用 RAISERROR 创建和返回用户定义的错误信息时，使用 sp_addmessage 添加用户定义的错误信息，使用 sp_dropmessage 删除用户定义的错误信息。

当出现错误时，错误号将放在 @@ERROR 函数中，该函数存储最新生成的错误号。对于严重级别为 1 到 10 的消息，@@ERROR 的默认设置为0。

示例

A. 创建特定消息

下例显示可能出现的两种错误。第一种错误很简单，生成的是静态消息。第二种错误则是在尝试修改的基础上动态生成的。

CREATE TRIGGER employee_insupd

ON employee

FOR INSERT, UPDATE

AS

/* Get the range of level for this job type from the jobs table. */

DECLARE @@MIN_LVL tinyint,

@@MAX_LVL tinyint,

@@EMP_LVL tinyint,

@@JOB_ID smallint

SELECT @@MIN_LVl = min_lvl,

@@MAX_LV = max_lvl,

@@ EMP_LVL = i.job_lvl,

@@JOB_ID = i.job_id

FROM employee e, jobs j, inserted i

WHERE e.emp_id = i.emp_id AND i.job_id = j.job_id

IF (@@JOB_ID = 1) and (@@EMP_lVl <> 10)

BEGIN

RAISERROR ('Job id 1 expects the default level of 10.', 16, 1)

ROLLBACK TRANSACTION

END

ELSE

IF NOT @@ EMP_LVL BETWEEN @@MIN_LVL AND @@MAX_LVL)

BEGIN

RAISERROR ('The level for job_id:%d should be between %d and %d.',

16, 1, @@JOB_ID, @@MIN_LVL, @@MAX_LVL)

ROLLBACK TRANSACTION

END

B. 在 sysmessages 中创建特殊消息

下例显示如何通过执行 employee_insupd 触发器获得与 RAISERROR 相同的效果，而 RAISERROR 使用给存储在 sysmessages 表中的消息传递参数的方法。该消息通过 sp_addmessage 系统存储过程，以消息号 50005 被添加到 sysmessages 表中。

说明 下例仅供举例说明。

RAISERROR (50005, 16, 1, @@JOB_ID, @@MIN_LVL, @@MAX_LVL)

错误信息Microsoft&reg; SQL Server™ 2000 在遇到问题时，根据严重级别，将把 sysmessages 系统表中的消息写入 SQL Server 错误日志和 Microsoft Windows&reg; 2000 或 Microsoft Windows NT&reg; 4.0 应用程序日志，或者将消息发送到客户端。

可以在遇到问题时由 SQL Server 返回错误信息，也可以使用 RAISERROR 语句手工生成错误信息。

RAISERROR 语句提供集中错误信息管理。RAISERROR 可以从 sysmessages 表检索现有条目，也可以使用硬编码（用户定义）消息。RAISERROR 返回用户定义的错误信息时，还设置系统变量记录所发生的错误。消息可以包括 C PRINTF 样式的格式字符串，该格式字符串可在运行时由 RAISERROR 指定的参数填充。这条消息在定义后就作为服务器错误信息发送回客户端。

无论是从 SQL Server 返回，还是通过 RAISERROR 语句返回，每条消息都包含：

唯一标识该错误信息的消息号。 表明问题类型的严重级别。 标识发出错误的来源的错误状态号（如果错误可以从多个位置发出）。 声明问题（有时还有可能的解决方法）的消息正文。 例如，如果访问的表不存在：

SELECT *

FROM bogus

发送到客户端的错误信息类似下面所示：

服务器：错误信息 208，级别 16，状态 1

对象名 'bogus' 无效。

查询 master 数据库中的 sysmessages 表可以查看 SQL Server 错误信息列表。有关 sysmessages 的更多信息，请参见系统错误信息。

错误信息严重级别 错误信息严重级别可用来表明 Microsoft&reg; SQL Server™ 2000 所遇到问题的类型。

严重级别为 10 的信息为信息消息，表明问题是由于输入信息时发生错误而产生的。严重级别为 11 到 16 的错误是由用户产生的，可以由用户修正。

严重级别从 17 到 25 的错误表明软件或硬件错误。当所发生的问题产生严重级别为 17 或更高的错误时，应通知系统管理员。系统管理员必须解析这些错误，并跟踪错误发生的频率。当发生级别为 17、18 或 19 的错误时，尽管某个特定的语句无法执行，但仍可继续。

系统管理员应对能生成严重级别从 17 到 25 的所有问题进行监视，并打印包含信息的错误日志，回找发生错误的位置。

如果问题影响了整个数据库，可以使用 DBCC CHECKDB（数据库）确定损坏的程度。DBCC 可以对必须删除的一些对象进行标识，并有选择地修复损坏。如果损坏范围大，则必须对数据库进行还原。

用 RAISERROR 指定用户定义的错误信息时，使用大于 50,000 的错误信息号以及从 0 到 18 的严重级别。只有系统管理员可以发出严重级别从 19 到 25 的 RAISERROR 错误。

严重级别 0 到 19 严重级别为 10 的错误信息为信息错误。严重级别从 11 到 16 的错误信息由用户生成并可以由用户修正。严重级别为 17 和 18 的错误信息是由资源或系统错误产生的；用户会话不会中断。

使用 sp_addmessage，可以将严重级别从 1 到 25 的用户定义消息添加到 sysmessages。只有系统管理员可以添加严重级别从 19 到 25 的消息。

对于严重级别为 17 和更高的错误信息，应向系统管理员报告。

严重级别 10：状态信息

这是信息消息，表明问题是由于用户输入信息有误而产生的。严重级别 0 在 SQL Server 中是见不到的。

严重级别 11 到 16

这些消息表明错误可由用户修正。

严重级别 17：资源不足

这些消息表明语句导致 SQL Server 用尽资源（如数据库的锁或磁盘空间）或超出了系统管理员设置的一些限制。

严重级别 18：检测到非严重内部错误

这些消息表明存在某种类型的内部软件问题，但语句执行完毕，并且到 SQL Server 的连接还保持着。例如，当 SQL Server 查询处理器在进行查询优化时检测到一个内部错误，则出现严重级别为 18 的消息。每次出现严重级别为 18 的消息时，都应告知系统管理员。

严重级别 19：资源中发生 SQL Server 错误

这些消息表明已超出了 nonconfigurable 内部限制，并且当前批处理终止。严重级别 19 错误很少发生；但是，一旦发生，必须由系统管理员或主要支持提供者修正。每次出现严重级别为 19 的消息时，都应告知系统管理员。

严重级别 20 到 25 严重级别从 20 到 25 表明有系统问题。这是些严重错误，意味着进程（完成语句中指定任务的程序代码）将不再运行。进程在停止前先冻结，记录有关发生内容的信息，然后终止。到 SQL Server 的客户连接将关闭，并且根据存在问题的不同，客户端有可能无法重新连接。

严重级别为 19 或更高的错误信息将停止当前的批处理。严重级别为 20 或更高的错误信息被认为是严重错误，将终止客户连接。此范围的错误信息可能影响数据库中的所有进程，并可能表明数据库或对象损坏。严重级别从 19 到 25 的错误信息均写入错误日志。

严重级别 20：当前进程中的 SQL Server 严重错误

这些消息表明语句遇到了问题。由于该问题所影响的只是当前进程，数据库本身损坏的可能性不大。

严重级别 21：数据库 (dbid) 进程中的 SQL Server 严重错误

这些消息表明遇到了影响当前数据库中所有进程的问题；但数据库本身损坏的可能性不大。

严重级别 22：SQL Server 严重错误表的完整性置疑

这些消息表明消息中所指定的表或索引已因软件或硬件问题而损坏。

严重级别 22 错误很少发生；但是，如果遇到该错误，请运行 DBCC CHECKDB 确定数据库中是否有其它对象也受损坏。问题有可能只存在于超速缓存中，而不是存在于磁盘本身。如果是这样，重新启动 SQL Server 将修正该问题。要继续工作，必须重新连接到 SQL Server。否则，用 DBCC 修复该问题。有些情况下，有必要还原数据库。

如果重新启动帮助不大，则问题存在于磁盘上。有时，摧毁在错误信息中指定的对象可以解决该问题。例如，如果消息说 SQL Server 在非聚集索引中发现长度为 0 的行，删除该索引然后重建。

严重级别 23：SQL Server 严重错误：数据库完整性置疑

这些消息表明由于硬件或软件问题，整个数据库完整性存在问题。

严重级别 23 错误很少发生；但是，如果遇到，请运行 DBCC CHECKDB 确定损坏的程度。问题有可能只存在于超速缓存中，而不是存在于磁盘本身。如果是这样，重新启动 SQL Server 将修正该问题。要继续工作，必须重新连接到 SQL Server。否则，用 DBCC 修复该问题。有些情况下，有必要重新启动数据库。

严重级别 24：硬件错误

这些消息表明某些类型的媒体失败。系统管理员可能必须重新装载数据库。可能还有必要给硬件厂商打电话。