It is important to be able to determine whether an event is a database event in order to know what the format of the _event-detail field is and whether to expect any child records in the _aud-audit-data-value table.

One way is to check the event definition and rely on the event name ending in .create or .delete or .update. All the internal policies conform to this. This can be checked in code as follows:

DEFINE VARIABLE lDbEvent AS LOGICAL NO-UNDO.
IF _event-name <> "":U AND
  (ENTRY(NUM-ENTRIES(_event-name,".":U),_event-name,".":U) = "create":U OR
   ENTRY(NUM-ENTRIES(_event-name,".":U),_event-name,".":U) = "delete":U OR 
   ENTRY(NUM-ENTRIES(_event-name,".":U),_event-name,".":U) = "update":U) THEN lDbEvent = TRUE.

This approach will work only if any user-defined events that relate to database events follow the same naming convention for the event name.

Another way is to check the contents of the _event-detail field for a specific format, as shown:

DEFINE VARIABLE lDbEvent AS LOGICAL NO-UNDO.
IF _event-detail <> "":U AND
  NUM-ENTRIES(ENTRY(1,_event-detail,CHR(7)),CHR(6)) = 4 THEN 
  lDbEvent = TRUE.

A similar approach could be used to identify other types of events with a specifically formatted _event-detail. The primary consideration is to ensure the event definition follows some sort of naming convention to make all this possible and to be able to fall back to the event definition itself to determine the format of audit-related fields.