P6 Caching - Not Ready for Prime Time

P6 Caching - Not Ready for Prime Time 

Emerald Associates

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.