P6 Caching - Not Ready for Prime Time
We have been using P6 v18.x with several clients and have seen some differing behavior related to caching. It appears the problem may have started as early as P6 v16.x. These clients are in varying environments; P6 Oracle SaaS, EAI Hosted, and on-premise - In short, anywhere where Oracle Cloud Connect is utilized.
We were excited to see the new form of caching that appeared in v17.x. We have clients with poor internet access and P6Web is not adequate for their needs - they need P6 Client. Everyone knows that P6 Client is very chatty and needs good bandwidth to work properly, so the idea that we can cache data and do heavy lifting on our desktop rather than on the server far away was great.
P6 caching works by copying data from the main P6 database to a SQLite database that is installed on the local machine - it is essentially a filtered replication process.
Unfortunately, we have seen several different problems:
1. Data getting lost - this was related to User Defined Field (UDF) data on the project level seeming to disappear. The user would go in and add data to the UDF. Once the user logged out the data would clear out of the UDF and not be there when the user logged in again.
2. Data appears for one user and not another, despite refreshing (F5) and/or hard refreshing (Shift F5):
1. We first saw this with our CAPPS tools that submit updates through the Primavera Webservices; it would show up fine for one user, but not for another. When we investigated, we found that the user who saw the data properly was connected using the normal client-server connection while the user connected with Cloud Connect couldn't see the updates. Once the Cloud Connect cache service was turned off, the CAPPS tools submissions appeared as they should.
2. Another issue with one of our clients was with filters. One user would be able to see all values displayed in the filter and another user would see all the field criteria, but no data values in the criteria.
3. Calendars not taking updates - when changing some calendar exceptions, the schedule was not recognizing the changes. A client user added a new project calendar that was copied from an existing calendar. Changes would be made and saved, but when the user scheduled the project and went back into the new project calendar, the calendar had reverted to the copied calendar values. When the user logged out and back in, the calendar would update and show the proper values.
4. P6 caching can chew up local hard drive space and memory every time you connect to a different database alias or if you have large numbers of baselines on the project because it downloads all global data and baselines of open projects to the local machine. In some cases, the workstation would run out of memory or hard drive space, causing P6 to lock up and crash.
So for clients who work in a multi-user environment, or who have large projects with many baseline projects, we have decided to try to uncheck the caching except in the very extreme occasions where the P6 user has very poor internet. We will see how this goes.
If you find that you are having the same issues and want to turn off caching for the time being, you can do the following: Click on Database. Select Database. Click Configure... Button. Click Next. Un-check the box next to “Enable Client-side Cache”. Click Next. Click Finish. Log in as usual.
About the Author
At Emerald Associates, Sue is an Implementation Specialist and has been successful at drawing on her accounting and project management background to consult with our diverse client base. With her friendly demeanor and strong communication skills, she has become a talented Primavera trainer and works very hard to effectively implement Oracle Primavera solutions that cater to each client’s unique organizational needs.