Expert, flexible training in the use of the most powerful scheduling software program in the world: Primavera P6 by Oracle. Call today! (916) 779-4145
Primavera Scheduling

All posts tagged Primavera XER

Put Your Primavera XER File on a Diet

Categories: Oracle XE Database, P6 Professional, POBS Table, Primavera P6, Primavera XER
Comments Off on Put Your Primavera XER File on a Diet
Primavera Scheduling

You have probably noticed that after using Primavera P6 for a while your XER files seem to be getting bigger. Actually, a lot bigger. Files that used to be under 1 MB are now more than 10 MB. This slows down the importing of XER files considerably and makes it harder to email files without using a large-file service  like Hightail or Dropbox.


According to Oracle, this problem affects Versions 7.0 and later.


The XER file format is the most popular way to exchange project data between databases. As a consultant, I always have to send my files to the client. There is another Primavera format – XML – but these files tend to be rather large compared to Primavera XER. The beauty of the XER format is that it is text-based, which normally results in a very small file.

Nevertheless, XER files have a bad habit of getting rather chubby, if not downright HUGE. This would be understandable if it served some purpose. Unfortunately, the increased size is a complete waste of space. And in some cases it takes so long to import the XER file that P6 effectively locks up. Not good.

Specifically, the problem is the POBS Table. Join the club if you have never heard of this data field. Here is the official explanation from Oracle as to the purpose:

Functions related to table POBS have not been implemented yet so the table has not been put to use. The table may be removed in a future release.

You do have to wonder, if Oracle has not found a purpose for the POBS Table yet, why has its use persisted for so long? This is not the first time a feature showed up without a purpose. For several years Primavera P6 displayed a colored bar next to the Activity Code Values. The default color was blue. Regardless, changing the color did nothing because the feature was intended for Visualizer, which had not been incorporated yet:

Activity Codes Menu

Since the POBS Table is not used at all, we might as well delete it. Granted, if your XER files are rather small it is not a necessary step. Until recently all of my XER files were reasonably sized considering the size of the projects. But starting several months ago my XER files started gorging themselves. A POBS Table with a few dozen lines suddenly had thousands of lines. Deleting the POBS Table became a necessity for me.

Assuming you are using an Oracle database it is rather easy to delete the POBS Table in the database so that export files do not include this table by running the following statement inside the database after backing it up:

  • delete from pobs;
  • commit;

**UPDATE** Please see my post regarding how to Delete POBS Data in an Oracle XE Database for more detailed instructions on how to execute the above commands.


Files being imported into the database, however, most likely will have the POBS Table. So it may become necessary to modify the XER files prior to importing them. Here are the steps:

  1. Make a copy of the XER file (just in case!)
  2. Open the XER file in a text editor like Notepad
  3. Find (Ctrl+F) the line that starts with %T POBS
  4. Select the following lines that start with:
    1. %T POBS
    2. %F (including all line content)
    3. %R (including all line content)
  5. Stop at the next %T
  6. Delete the above lines
  7. Save the XER file
  8. Import the XER file

Below is a screenshot showing each type of line that must be deleted:

POBS Table

Note that lines that start with %R may number in the hundreds or even thousands. The above image does not reflect the thousands of %R lines that existed in this particular XER file.

The next %T will be very close to the end of the file. The rest of the lines pertain to project data that should not be deleted, which is why we stop at the next %T. The biggest headache is getting all of the %R lines highlighted.

Still, deleting the POBS Table can yield startling results. Starting with a XER file that was 14.4 MB (14,377 KB) in size, I employed the technique described above to delete the POBS Table. The new XER file was just 105 KB (!)

It is always a good idea to make a backup copy of the XER file just in case you delete the wrong lines. But otherwise this is a quick and easy way to drastically reduce the size of XER files.

Update: starting in 2016, Oracle introduced SQLite as the default database for standalone users. This new database does not use the POBS table and therefore the problem I am describing no longer occurs.

Any comments or questions? Please email me.


Export Resources without Cost Data

Categories: Primavera P6, Primavera Resources
Comments Off on Export Resources without Cost Data

The purpose of exporting Primavera P6 files in “XER” format is to transmit all of the project data to another database. In many cases we are not looking to exclude any data. So how do we avoid sharing sensitive cost data with other parties? Contractors may not want owners, subcontractors and other parties to have access to this proprietary information.

There are two options for not sharing cost data. One option is to delete resource assignments altogether. We do this by copying the schedule inside Primavera P6 and un-checking the “Resource & Role Assignments box, as seen below:

Export Project without Resource Costs_1

 

 

 

 

 

 

While this option works perfectly well, the recipient will see no resources or roles in the schedule. What if we want the recipient of this file to be able to see the resource units but not the unit prices? This requires a different approach. Option 2 involves creating a new user and associated user profile who is not allowed to view cost data. When this user exports the file the resource rates will disappear but the resource assignments and units will remain intact.

First, we create a new user and label that person in such a way that we remember why this user was created in the first place. Go to Admin → Users. Below, I have added a new user with the name “Export User”:

Export Project without Resource Costs_2

 

 

 

 

 

 

 

Note that I have given this new user access to every project in my database by assigning this user to the highest level in the Organization Breakdown Structure (OBS). This is not absolutely necessary but it does make it easier to export any project without cost data.

Second, we need to assign the new user a Project Profile that excludes the ability to “View Project Costs/Financials”. Go to Admin → Security Profiles and select Project Profiles. In the screenshot below I have added a new Project Profile, “No Costs Exported”:

Export Project without Resource Costs_3

 

 

 

 

 

 

 

Also, I gave this new user no ability to modify schedules because the only purpose of this user is to export projects sans cost data. As soon as the project has been exported I will log back in using my normal user name.

Now we are ready to export a project with cost data. Keep in mind that you will need to log in as the new user first!

Questions or comments? Please feel free to contact me.