LISTERRS

LISTERRS reads a log file produced by DBBUILD or an update script generated by DBUPDGEN and lists the error and warning messages in the log.

Command-line syntax:

listerrs [-summary] file [min-severity]

`-summary`	Give only a summary of the error messages in the log: how many times and in how many files each message occurs.
file	A log file from DBBUILD or an update script to read.
min-severity	Only include a file in the output if it has generated a message with a severity level higher or equal to min-severity. Specify 11 to see only pure compilation errors that prevents objects from being created. Specify 9 to also see style errors, such as complatins for missing NULL/NOT NULL indicators in CREATE TABLE statements. The default for logs generated by DBBUILD is 10 and the default for logs generated by update scripts is 9. (Why? Well, you may want to produce warnings in your update script with RAISERROR, and you probably want to see these in the log. But if you specify severity level 10 to RAISERROR, SQL Server changes this to 0! So use 9 instead.) Note that once LISTERRS includes a file in the output, it includes all messages the file has generated, even those that fall below min-severity.

In many cases, the log files produced by DBBUILD or an update script generated by DBUPDGEN are very long and tedious to read. The log files are also likely to include many instances of message 2007, Cannot add rows to sysdepends..., emitted by SQL Server when there is a call to a missing stored procedure. These 2007s are often false alarms, because the missing procedure appears later in the build. Therefore you should read these logs with LISTERRS to see only the relevant problems in the file. By use of the min-severity argument, you can select how much you actually get to see.

The aforementioned message 2007 is handled specially. When LISTERRS can match the procedure name to the name of a file that was loaded successfully, LISTERRS does not display this instance of message 2007. (Note here that LISTERRS assumes that procedure and file names are the same.) If LISTERRS matches the procedure name to a file failed to load, the message 2007 is displayed if min-severity is 10 or lower; that is, this is handled a warning. If LISTERRS cannot match the name of the missing procedure at all, the instance of message 2007 is included in the output, regardless of the value of min-severity. To help you distinguish between this two cases, LISTERRS alters the text of the message to include any of the phrases which is the log file but failed to load or entirely missing in the database.

A message which is handled similarily is message -1000. This is a message generated by the AbaPerls file-loading process when it tries to update an assembly with ALTER ASSEMBLY, but gets an error from SQL Server that indicates the assembly has been changed in a way that is not compatible with objects that refer to the assembly. In this case AbaPerls drops all referring objects and issues one -1000 message for each object. If LISTERRS can determine that the object later was reloaded in the script, LISTERRS removes the message from the output. Else LISTERRS will augment the message so you can tell whether the object was missing or failed to load. Note that if the object was loaded before it was dropped, LISTERRS will regard it as missing. (As it is in fact is missing now.)

Note that when LISTERRS matches procedure names to file names, this applies only to the current and previous subsystems. If the procedure is loaded by a subsystem that DBBUILD or the update scripts builds later, this is an error, as an inner subsystem must not reference an outer subsystem.