Upgrading from P6 8.3 to 8.4: Stand Alone Installation

This past October, Oracle launched Primavera 6 8.4, an upgrade for v. 6.8.3, which was also a recent release. As the Oracle and media press-releases seems rather bland and low-key, we must assume most of the enhancements are under the hood; patches and fixes for 8.3 bugs, which is understandable, given the many improvements 8.3 featured. For what it’s worth, there is “new Visualizer functionality,” (I have never tried it) and some improvements to baseline updating. There are also improvements to Unifier, albeit cost-loading was never one of P6’s strong suits; however, the nature of these functional improvements not readily apparent.

This post discusses the 8.3 to 8.4 upgrade experience for a standalone installation and conversion of an Oracle XE database to SQLite. If you don’t have an Oracle XE database, consider yourself blessed. I have not tested the network installation, and therefore reserve comment on its operability, save to say I expect a network database upgrade must be quite an adventure. Hopefully, you already use a SQL database on your network that would obviate the need for conversion, and make the upgrade to 8.4 a cake-walk.

One notable exception to otherwise workaday fixes is support for iOS and Android devices including “offline support on the Apple iPad and iPhone.” I haven’t yet set this up, but it sounds interesting. The other big news is the introduction of SQLite into P6 installations, which is intended to replace the outdated Oracle XE database that 8.3 users can choose in lieu of SQL or SQL Express. Naturally, I wasn’t in a great hurry to upgrade, since my 8.3 had good functionality, until recently, when I tried to run Claimdigger.

First, let me say: pity the fool who 1) doesn’t back up his .xer and .plf files, and 2) doesn’t maintain a fallback 8.3 installation on another device (my laptop for instance). I was forced to upgrade to 8.4 when I realized Claimdigger – the critical analytic application that compares changes in .xer files –the P6 proprietary backup file format, would not initialize on my standalone installation. Without Claimdigger, I can’t run the reports I need to inform my narratives, which are required on all major projects. The reason why is complicated. Depending on who you talk to at Oracle, you might hear several theories. Essentially, it has to do with database-Java compatibility.

According to Oracle support, users with XE databases (mine was 10g) can no longer run the Java scripts necessary to start Claimdigger, a Java based internal application (API) – only the SQL databases can do that. It appears that Claimdigger/XE compatibility was lost in the 8.3 version, as 8.2 had full functionality. Unfortunately for me, I had an XE database. The kicker is that Claimdigger is also non-compatible with SQLite, or rather Oracle’s APIs are non-compatible with SQLite, so I opted for the old SQL Server Express.

One program operability issue I encumbered was loss of the ability to back up my database from 8.4 to 8.3 format:

I initiated a service request some days ago with support to investigate the matter, and they advise that this particular glitch will not be fixed by Oracle before the next release.

8.4 is still brand spanking new, and many Oracle support people aren’t yet up to speed with ‘known issues.’ Unfortunately, most of the lower-mid level support people you will encounter will have no idea what they are telling you. If you are considering the upgrade from XE, be prepared to spend some time with support: mostly wading through trial and error fixes that won’t work (8.4 knowledgebase is incipient) until you connect with one of Oracle’s higher-functioning support gurus. Oracle has many P6 support contractors; it just takes time to get past the support firewall.  Make sure you ask for a database specialist up front, otherwise you will spin your wheels with incompetents. The good news is Oracle is always building up their knowledgebase, which is accessible through Oracle’s support forums.

Once you set up your new SQL database, you’re good to go. You will then import your .xer and .plf files in your XE database to your SQL Server Express database. If you didn’t save and import your project layout (.plf) files, you will have to reformat each from scratch. Of course, keep up the practice of backing up your projects, .plfs, and storing them in the cloud. This is especially important to do just before you go for the upgrade. Unfortunately, if you are converting from XE, it appears that you must re-maintain and reassign project baselines for all of your projects, after you import them into the new database. I’m a small business, with a few large accounts, so re-baselining my projects was a snap; however, if you have a lot of projects that were baselined in XE, or likely any other database, you will have to redo all of them.

So if you’re using 8.3, and having no operability issues, my advice would be to wait for the next version release, which should resolve beta, or .0 issues, before you upgrade to 8.4. The trouble with beta releases is that they invariably are distributed before the support mechanisms are in place. Otherwise, take my advice and maintain your earlier version until 8.4 is ready for prime-time, which I would look for in about four to six-months.