LISTERRS reads a log file produced by any of the AbaPerls tools ABASQL, DBBUILD or an update script generated by DBUPDGEN. These log files are very verbose and tedious to read directly. LISTERRS extracts the error and warning messages in the log and suppresses errors and warnings that it can conclude have been addressed by later loads in the log file. A log file can consist of several appended logs.

   Command-line syntax
   Structure of the Output
   Dangling References

Command-line syntax

listerrs [-summary] [-lax] file [min-severity]
‑summary Rather than printing the full output for each file, LISTERRS only lists each unique error message in the log file together with the the number of occurrences and the number of files the message appears in.
-lax Changes the how LISTERRS matches messages of missing stored procedures with later loads of the missing procedure. Normally, LISTERRS only considers it a match, if the missing procedure is loaded within the same subsystem, but when ‑lax is in effect, this restriction is lifted.
file A log file produced by one of more executions of ABASQL, DBBUILD or an update script.
min-severity Instructs LISTERRS to only include messages that have at least the specified severity. Specify 11 to see only errors. Specify 10 to also see warnings. Specify 9 to also see style errors, like missing NULL indicates in table definitions. Specify 8 to also see diagnostic messages from update scripts.
   The default is 10 for logs from DBBUILD or ABASQL, and 9 for logs from update scripts. (This is because, if you want to produce warnings from the SQL part of your table updates, you cannot use level 10, since SQL Server changes 10 to 0.) Thus, if your log file consists of logs from both DBBUILD and update scripts (see below), LISTERRS applies a different default to different parts of the log file.
   You cannot specify a value higher than 11.

Structure of the Output

First some terminology. A file load is the loading of a single from disk or version control. For instance:

ABALOAD ap_objtype.typ
GET $/AbaPerls/sql/type/ap_objtype.typ

A log is the output from a single execution of ABASQL, DBBUILD or an update script. The logs can be appended in a single log file (by specifying ++ before the filename with the ‑log option.) All logs in the file must be for the same server and database. If this is not the case, LISTERRS aborts. (If you have a number of separate log files, you can manually concatenate these to one log. You need to be careful to concatenate the logs so that they come in chronological order.)

For each file-load in the log file, LISTERRS checks if there is a message which has a severity that is greater or equal to min-severity. In this case, LISTERRS includes the full output for the file-load in its output (with the exception for resolved dangling references, as discussed below). However, if the same file is loaded more than once in the same log file, LISTERRS only considers the last load of the file. Say that you run two update scripts for the same subsystem, and in the first script a_sp.sp fails with some stupid syntax error. The second update script loads a corrected version of a_sp.sp, why LISTERRS assumes that you are not interested in the first error. (Beware, though that for some types of files, for instance .tbl and .ins files, an error in the first load may yield consequential errors which may be difficult to understand if you only read the output from LISTERRS. When in doubt, consult the original log file.)

The log file may include file-loads from many subsystems. LISTERRS prints the header for a subsystem, only if there are any file-loads to display for the subsystem. Likewise, LISTERRS only prints the header of a log, if any subsystem in the log has produced any output.

Before it completes, LISTERRS always print a final summary, as in this example

A total of 58 message(s) in 27 file load(s).
There were in total 147 logs in the file.

If there is a single log in the file, the second line is not printed.

Dangling References

A dangling reference for LISTERRS is a file or an object which is listed as missing or forcibly dropped in one of the messages ‑2007, ‑1001, ‑1000 and 2007. If this object/file is not loaded later in the script, LISTERRS considers this an error. These messages all have severity 10 in the log files. Depending on its findings, LISTERRS may remove the message from the log or change the severity to 16.

Message 2007 – Produced by SQL Server when there is a call to a non-existing stored procedure. In SQL 2008, this message reads: The module '%s' depends on the missing object '%s'. The module will still be created; however, it cannot run successfully until the object exists. The text in earlier versions of SQL Server is different, but the gist is the same. (SQL Server produces the message with level 0, but AbaPerls changes the level to 10.) Starting with AbaPerls version L1.0.0290, AbaPerls discards this message of favour its own message, ‑2007.

Message ‑2007 – Produced by AbaPerls  for the same reason that SQL Server produces message 2007. The text is simply Stored procedure '%s' not found. LISTERRS handles messages 2007 and ‑2007 in the same way, and for the sake of simplicity, the remaining text uses 2007 to refer to both.

Messages ‑1000 and ‑1001 – These message are produced by AbaPerls itself in situations when it drops objects in order to be able to carry out an operation. For instance, to load a new definition of a table type, AbaPerls needs to drop all procedures and functions that use the table type in their parameter list. When AbaPerls uses message ‑1000, this is produced once for every object that is dropped. This message reads Object '%s' dropped because of dependency. Make sure it is reloaded. In contrast, when using message ‑1001 there is only one occurrance of the message which lists all affected object/files. Here is one example:

Msg -1001, Level 10, Line 49, $/blank test/sql/tbl/bankholidays.tbl
The files below from other subsystems are listed as referencing the table 'bankholidays'.
You must ensure that these files are reloaded.

The exact text for message ‑1001 depends on the context where the message is produced. AbaPerls lists file name in the case where a file can hold multiple objects, such as trigger and index files.

When LISTERRS encounters any of these messages, it records the dangling reference(s), and monitors that dangling references is loaded later in the log. There are a number of possible outcomes:

The reference is not loaded at all. In this case, LISTERRS adds the tag MISSING IN THE LOG to the reference in the original message, and changes the severity of the message to level 16. For message 2007, this also includes the case that the missing procedure is loaded in a different subsystem, since the philosophy of AbaSec is that inner subsystems should not refer to outer subsystems. However, you can override this with the ‑lax option.

The reference is loaded successfully. The message is removed from the output entirely, and if there is no other message with at least min-severity for the referencing file-load, the load will not be included in the output at all. For message ‑1001, which can list several references, the reference is removed from the message, and the message is not removed until LISTERRS have found file-loads for all references. For message 2007, the reference must have been loaded in the same subsystem, unless ‑lax is in effect.

The reference is loaded with errors. In this case, LISTERRS adds the tag Failed to load to the file name in the message. The severity level does not change.

The reference is deleted. That is, the reference appears in the OBSOLETE-FILES section of an update script or loaded with ABASQL ‑nocreate. For messages ‑1000 and ‑1001, this is the same as a successful load (since it indicates that the dangling reference has been handled). For message 2007, LISTERRS adds the tag HAS BEEN DELETED and changes the severity level to 16, since this is likely to be an error.

The reference is a site-specific file which is skipped (because it not match the setting of the ‑site option). LISTERRS adds the tag SKIPPPED to the file, and changes severity to 16.