The subject of database lg files was approved by our Product Management under the following IDEAS section, which is available since OpenEdge 11.7.3, OpenEdge 12.1
which takes a list of messages to omit from the .lg file (for SQL and ABL connections).
to remove private information from messages that are printed.
.lg file management, provides a flexible mechanism beyond PROLOG to:
Progress does not publish a specific set of error codes or messages to parse database logs for 'areas of concern'.
The database .lg file has a column to indicate the S
everity of the message after the Task ID column:
[yy/mm/dd@hh:mm:ss.uuushhmm] P-nnnnnn T-nnnnnn S name nnn: (nnnnn) Message
- I - Information; which can be ignored in initial scans and may be needed later while further investigating logged events.
- W - Warning; these messages are sometimes ignored at peril because some error messages are treated like warnings in certain contexts and errors in other contexts.
- F - Fatal error; are the easiest first parse for bearing in mind that less-critical messages like "cannot disable ai it is not enabled .." are flagged "F" which may or may not be critical depending on the context of the investigation.
Typically customers start with the "Fatal
" Severity and build their list and groups of error messages to parse for up over time. Caution should be exercised when using error numbers,
as these change between versions . The following key words catch most instances requiring attention as a starting point:
denied, failed, failure, unable, cannot, dbkey, recid, delete, error, complete, exceed, open, index, attempted, bk*, found, semAdd, ABNORMAL, dead, died, lk, socket
Consider reviewing the data in DLC/prohelp/msgdata
(essentially the warnings for messages) which provide a more easily set of text files for finding common key words in promsgs to search for.