That is the snapshot object used as the master of the audit job.
Can you clarify what you are trying to get – the result of an audit job or the result of a snapshot job ? an audit job does not generate snapshot results, nor does the audit job run a snapshot job.
Hi Bill, thanks for the response.
At the root of it, what I'm trying to do is some safe cleaning of database data. If I have a snapshot job, and it has many runs, I'd like to clean out the old runs via script. However, I do not want to risk deleting a run whose results are being used as the Master in an audit job.
So my thinking was to look at the snapshot result that is listed as the Master in the Audit job, and then backtrack from there to the snapshot run that generated the result in use, and protect that run from a delete routine on all the other runs for that snapshot job.
Run (8/16) - Used as Target in an audit job, don't delete
Run (8/15) - Recent, don't delete
Run (8/14) - Recent, don't delete
Run (8/13) - Used as Master in an audit job, don't delete
Run (8/12) - Old, delete
Run (8/11) - Old, delete
Run (8/10) - Old, delete
I'd love to use the Retention Policy property, but I'm afraid it will kill snapshot job runs that are being used by an audit job. Much of my script works fine right now, I've just hit a wall on how to protect certain runs from being deleted based on the above criteria.
Set the RESULT_RETENTION_POLICY based on how much you want to keep. The cleanup should not delete anything from the db (but might from the ui) that is actively in use. there should be no need for what you are doing. have you found otherwise ?
What cleanup commands are you running in your env ?