If you dont want to committ changes everytime you update the schedule is to establish a updating cycle. Ie
Every Friday is a schedule update date. (Everyone update their own progress and change the data date)
Every Monday is a scheudle review date. (Everyone review all the schedule interlink and discuss if any critical issue arise)
That way you will not have a problem when someone changing the progress of an interlink activity when you update your acitivities. So you dont need to constantly pressing F5 and F10. At the same time you 100% sure that come Monday the entire schedule is updated.
Scheduling in P3e/c you need to breakdown into projects, when the projects is just too big to handle, ie too many users need to access to the system you should create a EPS with the project ID where inidividual can excusive access to their project while update happens. Remember P3e/c is a real time database, and with data base when you editing the record you actually lock the record of the field in the database table.
Once you splite the projects into responsibility, you can then access to the schedule directly and dont need to press F10 or F5 anymore.
It seems that the project you discribe do not have any centralised scheduler to handle the update. ie all the project engineers updating the schedule.
The best way to handle this situations is remember when you are updating the schedule you are updating part of the time line. To syn the update you better draw a process diagram and schedule everyone have to update their schedule by certain time of the month before reporting. That way you can ensure the report produce is all updated. Otherwise you may print a report while someone is doing the update. However, this is only for reporting, for daily operation it will not stop anyone update the schedule at any time of the date. The only thing is you a updating and reviewing a snap shot (time) of the schedule instead of syn time version (like end of the month report) of the schedule. (Hope you understand) And that is part of the deal if you using a database in a multi-users enviornment.
Member for
22 years 8 monthsRE: Scheduling in P3e/c
If you dont want to committ changes everytime you update the schedule is to establish a updating cycle. Ie
Every Friday is a schedule update date. (Everyone update their own progress and change the data date)
Every Monday is a scheudle review date. (Everyone review all the schedule interlink and discuss if any critical issue arise)
That way you will not have a problem when someone changing the progress of an interlink activity when you update your acitivities. So you dont need to constantly pressing F5 and F10. At the same time you 100% sure that come Monday the entire schedule is updated.
Member for
16 years 9 monthsRE: Scheduling in P3e/c
Commit is an oracle command that simply saves/writes new/altered data into the database
Member for
21 years 9 monthsRE: Scheduling in P3e/c
Thank you Alex,
The reason we do not have a centralised scheduler is we have some 46,000 tasks which would take one scheduler a considerable amount of time.
Have you haerd of this Commit Changes before?
It seems that for any updating to show on all the users Desktop we have to go through the process as formentioned.
Member for
23 years 8 monthsRE: Scheduling in P3e/c
btw, is it help to shorten the screen refresh time interval? Not sure any setting on this one.
Member for
23 years 8 monthsRE: Scheduling in P3e/c
I agree Alexs proposed. Although Im working on P3 with user more than 20, each responsible on his own sub-project.
When I schedule at master level, I inform all parties to close their opened sub-projects and re-open after I schedule.
Member for
22 years 8 monthsRE: Scheduling in P3e/c
Scheduling in P3e/c you need to breakdown into projects, when the projects is just too big to handle, ie too many users need to access to the system you should create a EPS with the project ID where inidividual can excusive access to their project while update happens. Remember P3e/c is a real time database, and with data base when you editing the record you actually lock the record of the field in the database table.
Once you splite the projects into responsibility, you can then access to the schedule directly and dont need to press F10 or F5 anymore.
It seems that the project you discribe do not have any centralised scheduler to handle the update. ie all the project engineers updating the schedule.
The best way to handle this situations is remember when you are updating the schedule you are updating part of the time line. To syn the update you better draw a process diagram and schedule everyone have to update their schedule by certain time of the month before reporting. That way you can ensure the report produce is all updated. Otherwise you may print a report while someone is doing the update. However, this is only for reporting, for daily operation it will not stop anyone update the schedule at any time of the date. The only thing is you a updating and reviewing a snap shot (time) of the schedule instead of syn time version (like end of the month report) of the schedule. (Hope you understand) And that is part of the deal if you using a database in a multi-users enviornment.
Same if you are using P3.
Regards
Alex