Project security and finish auto changes but old value equal to new value

[JEC]

Hello,
There are some daily jobs that changes the security and finish field of a project. But the values are totally the same. I have checked the process tab and could find process that ran on the same day.

Then I assume it's the ootb job (Update Aggregated Data) that is doing the change since the time is the closest. If the picture below is too small, I have also included in the attachment.


Financial status of this project is closed. 

Does anyone know what's causing this issue?

[Jose Ignacio Mugica]

Hi,
Could you check if any job, process runs at the given time?
Any XOG update on those projects?
I see that the update occurs at around 6.30 - 6.40 am on daily basis.
All the updates are done by CA PPM, so I would assume any job that is scheduled by the CA PPM admin user
Regards
Joxi

[JEC]

Hi Jose,
I have checked the process tab in this project and there's no process being ran daily. I assume if this is caused by a process, it would be recorded under the process tab right.

Another question is- what is the efficient way to check if there is any XOG update on these projects?

Thanks

[Jose Ignacio Mugica]

Hi,
If processes are run at instance level, you would see them on the processes tab.
You might have a global process being executed through a job "Execute a Process" type. If it is a global process you will not see it at instance level.
Can you also check what jobs are scheduled to be run around the affected time? Jobs that run daily at about 6.30 am?
This might also give a hint on what might be happening.
Regards

[David Morton]

Audit functionality is implemented by database triggers, so *any* updates to the database tables for an audited attribute will cause new entries in the audit table (CMN_AUDITS).

There are various things I would investigate ; as others have mentioned look at *ANY* (bespoke) jobs that are running on your system - but also look at *ANY* interfaces, *ANY* custom triggers, *ANY* adhoc updates.

The reason I emphasise *ANY* is that the date/time stamp (and the "last updated by") on the audit table can be "misleading" where the data has been updated by a non-stock (i.e. bespoke) method, because if such a thing only updates the single column on the audited table, then the when and who information on the audit log will be wrong as this is copied from the base table itself rather than being generated by the trigger - what I am saying is that if the update does not also set the last_updated_by and last_updated_date on the base table then the last_updated_by and last_updated_date values in the audit log will actually be the "previous" update to the table, not the actual update.

The other thing I'd look at is the raw data on the CMN_AUDIT table, the "Finish" field is a date/time field and since the screen only shows you the date element you are missing some possibly interesting information (if a field has not changed, then the trigger should not be auditing it at all, so perhaps looking at the raw data on the table might help you understand what is actually going on?