Guild of Project Controls: Compendium | Roles | Assessment | Certifications | Membership

Tips on using this forum..

(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?

(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.

Tracking schedule changes

6 replies [Last post]
Phil Bedford
User offline. Last seen 1 year 7 weeks ago. Offline
Joined: 23 Jun 2016
Posts: 18

We have a database with 8 users, all with the same level of access. One of the users claims that "someone" has been in and changed one of his schedules.

I know I can see who has the schedule currently open, but is there any way to track who has opened the schedule in the last say 24hrs or so?

Thanks in advance.

Replies

Rafael Davila
User offline. Last seen 21 hours 54 min ago. Offline
Joined: 1 Mar 2004
Posts: 5228
  • Forever chasing for unauthorized changes is nuts!
  • That anyone can mess your schedule is scary.
  • The problem is with giving to everyone editing rights to all projects.
  • Better issue a good access control system, free-for-all is not a good idea.
  • It is a no-brainer, if every user is to have his own particular access rights, then an individual access profile shall be issued for each user.
Zoltan Palffy
User offline. Last seen 3 days 6 hours ago. Offline
Joined: 13 Jul 2009
Posts: 3089
Groups: None

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:

  1. Login to P6
  2. Browse to Administer, Application Settings
  3. Select the Auditing tab

you set the level of the audit from leve 0 to level 3

Level 0No Audit
Level 1Row-level Audit. Audit only the operation without column details
Level 2Column-level Audit without Blobs. Audit changes to the data at the column level but without Blob changes
Level 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 auditSample 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>'; 
Rafael Davila
User offline. Last seen 21 hours 54 min ago. Offline
Joined: 1 Mar 2004
Posts: 5228

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!

Image-035

Image-036
 

Phil Bedford
User offline. Last seen 1 year 7 weeks ago. Offline
Joined: 23 Jun 2016
Posts: 18

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.

Phil Bedford
User offline. Last seen 1 year 7 weeks ago. Offline
Joined: 23 Jun 2016
Posts: 18

.

Santosh Bhat
User offline. Last seen 51 weeks 1 day ago. Offline
Joined: 15 Apr 2005
Posts: 381

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:

  •  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.