From here, the
sql_severity column is the "severity of any SQL Server error."
When this column has the value 0, that means either no message was returned (and it's therefore a magic value), or a message with severity 0 was returned. I would argue this is a bad table design, as the column does not allow
It's almost the same thing with the
sql_message_id column. This column will contain 0 when no message was returned -- in this case, though, it's purely a magic value, as there's no message id 0 (run
SELECT * FROM sys.messages WHERE message_id = 0;).
You may want to clarify the intent of the report query you've inherited, because only comparing the
sql_severity column may not do exactly what the author thought. (Severity 0 errors being raised are undoubtedly rare, but hey, you asked.)
If it's supposed to look for steps that returned a message, then it should check for
sql_message_id > 0. As mentioned, it's completely possible that a job step can have a
sql_severity > 0 and/or
sql_message_id > 0 while still succeed. **
If the query is supposed to look for failed steps, it should be looking at the
run_status column instead.
** You can try this yourself by creating and running a job with a T-SQL step that simply calls