Problem: How can one log and trace out that XYZ user has accessed N records from a DB table. In this particular scenario the DB will be accessed thru Progress Editor (multi user session). Progress OE version 11.5.1 Enterprise RDBMS
Note: This is related to GDPR that comes into effect in EU from 25-May-2018.
Auditing does not support FIND events.
You can create user defined audit events but those are only as good as the code that fires them (and they won't do you any good if the code is bypassed by an ad-hoc query).
You could define FIND triggers but:
1) If the data is frequently accessed you will be imposing a very significant performance penalty. Users are likely to hunt you down and give you "feedback". (This is why auditing does not support FIND. The performance impact would be *huge*.)
2) There are many ways that FIND triggers might not catch everything. For instance, triggers can be disabled in code. And whatever audit trail they might create could possibly be tampered with.
I concur that Auditing finds is not a particular good idea. However, there's also Application events in the auditing mechanism which allows you to log when for example somebody open the Employee Details screen/page of Y instead of logging the read of the records. This way you can at least see that person X accessed the employee details of Y, which should be enough in most use cases (imho).
According to documentation (documentation.progress.com/.../index.html, you can report creates, updates and deletes for a record.
Auditing does not support FIND events.
You can create user defined audit events but those are only as good as the code that fires them (and they won't do you any good if the code is bypassed by an ad-hoc query).
You could define FIND triggers but:
1) If the data is frequently accessed you will be imposing a very significant performance penalty. Users are likely to hunt you down and give you "feedback". (This is why auditing does not support FIND. The performance impact would be *huge*.)
2) There are many ways that FIND triggers might not catch everything. For instance, triggers can be disabled in code. And whatever audit trail they might create could possibly be tampered with.
I concur that Auditing finds is not a particular good idea. However, there's also Application events in the auditing mechanism which allows you to log when for example somebody open the Employee Details screen/page of Y instead of logging the read of the records. This way you can at least see that person X accessed the employee details of Y, which should be enough in most use cases (imho).
This GDPR and Auditing is getting a monster.
KPMG requests that especially every change of a database admin (user with Admin rights on the server too) should be registered somewhere.
I agree with [mention:d62612d7bdcd488685a455194e7a8938:e9ed411860ed4f2ba0265705b8793d05] and [mention:dc2ff39fa15940708b78017f1194db6a:e9ed411860ed4f2ba0265705b8793d05] both. Logging read events is a sensitive topic and we should be really careful as it can have great impact on the system's performance. So log only what you really need to i.e. sensitive data in context of GDPR law. We should refrain ourselves from generalising this solution for all table accesses.
[mention:60ce6e5c50d843baae631b41add36c1b:e9ed411860ed4f2ba0265705b8793d05] - If you are looking to log all changes (i.e. CUD but not read) then check Change Data Capture which is available in OpenEdge version 11.7 onwards.
Thanks for you replies guys.
I doubt that GDPR requires recording all reads. When Sarbanes-Oxley came into effect in the US, there were people who claimed that it required recording reads but it does not.
Oracle has this feature:
AUDIT update table BY user1, user2
Not sure how this undoubtedly very nice Oracle feature is going to help [mention:9ef4e07cd35c4f9686555c3ceee07455:e9ed411860ed4f2ba0265705b8793d05] registering reads on important events on his OpenEdge database...