Re: STRSQL audit log -- is the 'journal' of the container of the data; no statement auditing

Journal the files. The journal serves as the audit trail for the insert\update\delete of the data in the files.

If there is a requirement to journal statements... I think that had been a requirement submitted a few times. That is a hard sell since the journal provides the net effect, which would satisfy almost any audit. However for auditing of dynamic DML statements, one could use the DB Open Exit with the feature to retrieve the last\current SQL statement, possibly only in combination with a program stack review. I would suggest avoiding that exercise, except in the most excessively strict audit environments; best to just defer to journaling.

Submit a requirement for statement level auditing as an enhancement over command level auditing if that is perceived as necessary for the business. Be sure to be clear on whether only dynamic or if embedded statements too, and if only DML or also DDL. FWiW viewing the idea of logging the SQL as effectively logging HLL statements, the language being SQL, might seem a bit daft; be clear on what are the actual requirements to satisfy the business needs.

I had envisioned at one time that shipping in QSYS, some *CMD objects like SQLUPDATE, SQLINSERT, & SQLDELETE, could enable command auditing for the equivalent dynamic statements. Such commands invoked via the SQL runtime when the statement was prepared would cause any activated command auditing to occur. And at the same time enable controlling the use of the statement due to either the user authority restrictions or command environment rules as controlled by the command invocation.

Regards, Chuck

Paul E. Fenstermacher wrote:

Our auditors want us to maintain a log of activity around this command
like we can do with DFU and DBU. Anyone know a way to do this? Thanks.