Maybe you are looking at the wrong table. If you do not have such table then I do not expect you to be able to reconstruct it after the facts.
In Spider Project we have an audit table called Logbook. You can set up the maximum number of entries to be up to 10,000; it should be good enough to make any corrections in time. If after 10,000 entries you might still need to look at previos entries then you sholud periodically backup the table as a separate document for future view, say backup the table once a week. Auditing schedule entries for corrections after a week can be too late.
- One of the users claims that "someone" has been in and changed one of his schedules.
I would recommend allowing full access to a single person per job in addition to the system administrator and grant others acess rights to only view some WBS sections with access to view a limited number of cost codes.
Chasing for unauthorized changes is nuts!
Member for
16 years 3 months
Member for16 years3 months
Submitted by Zoltan Palffy on Fri, 2020-11-20 13:59
to see who logged in when you can go into the database and run a query depending on what databse that you are running
Oracle:
select unique login_date, user_name from (select * from usessaud order by login_date DESC) where rownum < (select count(distinct user_name) from usessaud) + 1;
SQL Server:
Select login_date,user_name from usessaud as U where login_date =(Select MAX(login_date) from usessaud where user_name= U.user_name);
you can also see what chnages were made buy running a query using an audit trail
To access the database auditing application settings:
Login to P6
Browse to Administer, Application Settings
Select the Auditing tab
you set the level of the audit from leve 0 to level 3
Level 0No AuditLevel 1Row-level Audit. Audit only the operation without column detailsLevel 2Column-level Audit without Blobs. Audit changes to the data at the column level but without Blob changesLevel 3Full Audit. Audit changes to the data at the column level including Blob changes (Oracle only)
the level is set in the query liste dbelow
auditing_enable(<table_name>,<level>)
auditing_disable(<table_name>)
Examples for Oracle:
Enable full auditing on all tables: exec auditing_enable(null,3);
Enable level one auditing on the task table: exec auditing_enable('TASK',1);
Disable auditing on PROJWBS: exec auditing_disable('PROJWBS');
Disable auditing on completely: exec auditing_disable(null);
Example for SQL:
Enable level 2 auditing on the ACCOUNT table:
EXEC auditing_enable
@ptable_name = N'account',
@plevel = 2
You can then review the audit
Sample Queries to Retrieve Auditing Data:
To view all auditing data:
SELECT * FROM PRMAUDIT;
To view auditing data for one table:
SELECT * FROM PRMAUDIT WHERE table_name = '<Table Name>';
To view auditing data for one user:
SELECT * FROM PRMAUDIT WHERE prm_user_name = '<User Name>';
I don't think that level of auditting is easily available from the P6 front end. Perhaps someone who can access the datatables may be able to.
There is something you can do, in the activity columns, you can include these two columns to be displayed:
Last Modified By - this will give you the users name, note that this may not be 100% accurate if say, the entire project has been copied
Last Modified Date, this will also tell you when it was last modified, but same caveat as above.
Having multuple users in a the same project is a tricky balance, especially if they end up working in the same sections of the project.
Remember that when a user makes a change, it may not be committed to the database until they take an action to commit the change, such as pressing F9. Pressing F10 forces data to be committed to the database. And then sometimes you will need to press F5 to refresh from the database.
There could be a scenario that the changes one user makes are overridden by another users actions because the other users data was committed to the database, and the first user has not refreshed those changes yet.
Member for
21 years 8 monthsForever chasing for
Member for
21 years 8 monthsMaybe you are looking at the
Maybe you are looking at the wrong table. If you do not have such table then I do not expect you to be able to reconstruct it after the facts.
In Spider Project we have an audit table called Logbook. You can set up the maximum number of entries to be up to 10,000; it should be good enough to make any corrections in time. If after 10,000 entries you might still need to look at previos entries then you sholud periodically backup the table as a separate document for future view, say backup the table once a week. Auditing schedule entries for corrections after a week can be too late.
- One of the users claims that "someone" has been in and changed one of his schedules.
I would recommend allowing full access to a single person per job in addition to the system administrator and grant others acess rights to only view some WBS sections with access to view a limited number of cost codes.
Chasing for unauthorized changes is nuts!
Member for
16 years 3 monthsto see who logged in when you
to see who logged in when you can go into the database and run a query depending on what databse that you are running
Oracle:
SQL Server:
Select login_date,user_name from usessaud as U where login_date =(Select MAX(login_date) from usessaud where user_name= U.user_name);
you can also see what chnages were made buy running a query using an audit trail
To access the database auditing application settings:
you set the level of the audit from leve 0 to level 3
Level 0No AuditLevel 1Row-level Audit. Audit only the operation without column detailsLevel 2Column-level Audit without Blobs. Audit changes to the data at the column level but without Blob changesLevel 3Full Audit. Audit changes to the data at the column level including Blob changes (Oracle only)
the level is set in the query liste dbelow
Example for SQL:
Member for
9 years 4 months.
.
Member for
9 years 4 monthsThanks for the reply Santosh
Thanks for the reply Santosh - I'll keep the Modified By column in mind.
Ive requested the database administrators to have a look and see if they have any logging available in the back end.
Member for
20 years 6 monthsPhil,I don't think that level
Phil,
I don't think that level of auditting is easily available from the P6 front end. Perhaps someone who can access the datatables may be able to.
There is something you can do, in the activity columns, you can include these two columns to be displayed:
Having multuple users in a the same project is a tricky balance, especially if they end up working in the same sections of the project.
Remember that when a user makes a change, it may not be committed to the database until they take an action to commit the change, such as pressing F9. Pressing F10 forces data to be committed to the database. And then sometimes you will need to press F5 to refresh from the database.
There could be a scenario that the changes one user makes are overridden by another users actions because the other users data was committed to the database, and the first user has not refreshed those changes yet.