question cannot be answered with a single sentence. So I would like to know if
you still need answers or if you know already what you need to know.
right, but it’s not the whole story. I’ll try to give a complete picture in the
next days ...
The AE DB
Revision Report can create detailed information reports on:
Some of the
underlying data is collected automatically anyway.
for example, is basically theStatisticwhich is stored in theAH table.
So the Revision Report takes this data from the AH table.
tracking object modifications there is already another feature, theVersion
Management for Objects, which is stored in thetables OH and OX. Version
Management is automatically activated when the logging for the Revision Report
which is not available so far, is stored in theXAO table.
report in created using the UCYBDBRR program, it will collect data from the
tables mentioned above, based on the parameters given.
when the start parameter –A is used the archive flags are set. The DB Reorg
process will only remove entries from the database where the archive flag is
example:If a system is sowing the effect that Version Management Objects are
not deleted after 30 days, which is set for the DB Reorg process (and it's running ok), the reason can be that no Revision Report was created
so far (or the –A parameter was not used).
In the end
the AE DB Revision Report is a very powerful feature, however when is swicht
on, it’s recommended to run reports regularly to avoid growing DB tables.
Enjoy the Revision
Hi Josef_Scharl_103. I am not quite clear on what you mean about the -A flag. I'm contemplating turning on the revision report as well. We currently keep AH records for 400 days and RH, MELD records for 125. If we enable the revision report (object_audit = y in UC_CLIENT_SETTINGS) then we would also probably set it in the UC_UTILITY_REORG to keep 125 days for OBJECT_AUDIT as well. Where does -A flag come in. I'm not quite sure. Thanks.
The parameter –A of the UCYBDBRR program marks the entry in the XAO table as “Reversion Report was created – therefore it’s ok to reorganize the record”. I think this should prevent the UC4 DB.Reorg / DB.Unload from removing XAO entries before a Revision Report was created.
I’ve seen many environments where Object Audit was switched on, but no / not all Reversion Reports were created ==> this causes a growing XAO table …
However there is also the “Only reorg revised Object Audits” option at the DB.Reorg utility. I think when it’s not activated it will remove XAO entries, regardless if they were already used for a Report or not:
I hope this makes it clearer.Anyhow, I would recommend to keep an eye on the XAO table after activating Object Audit.
Basically the Audit records are in the DB, mainly in the XAO table. And they will stay forever depending on the settings you make in the UC_UTILITY_REORG variable for the client where Audit is activated.
As Josef indicates, the parameter for the "Reorg Object Audit" is indicating how many days you want to keep the audit records in the DB. Then the reorg process will take care of them, with the possibility to check if they have been "revised" first a.k.a. archived in a csv file. This what the ucybdbrr is doing, extracting the records and saving them into a csv file (Windows format regardless if the utility runs on windows or unix/linux ....) and "flagging" or not the archive flag on them.
The only small detail is that the "archive" flag must be set using the -A option with the ucybdrr utility and another parameter is the start timestamp and end timestamp of the scope of the action of the ucybdrr. If you are not limitating the scope, you will extract the whole audit information in the DB. And if you are not setting the -A option, you will not remove the records from the DB if you have set the option "Only reorg revised Object Audits".
Fortunately someone, for once, has been to the end of the logic and there is another parameter -X that allows for the ucybdbrr output. to select only records that have not the "archive" flag set . So if you want to extract all audit records to save an archive in csv format every day, you can use the command ucybdbrr -F* -A -X to do it. and set the retention to 125 days to be able to do some reports in csv for specific dates or audit types in this 125 days time window.
Personnally I would recommend also to run this command ucybdbrr -F<audit type> -X for every audit type before running the command ucybdbrr -F* -A -X that is doing a global extract and flag records. Makes search easier when looking for one type of action specifically, like a move from one folder to another or a load from a transport.
Hope this can help you to decide how, when and how long you want to keep the audit records.