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.
Post a Comment