Some of you have probably started running into this problem back in May where XER project files are getting larger in size (beyond 10MB) and it is a lot slower to import/export these files back with P6. If you have projects that have a lot of repetition, equalling up to tens of thousands of activities, then this will affect you.
At some point during release 8.3, the existence of POBS tables got introduced (completely unheard of until now) and recently started affecting the XER imports. POBS inside the database is called “Performing Organization Breakdown Structure”. Hmmm… it sounds like it has something to do with the OBS. According to Oracle, nothing has actually been implemented yet regarding this table. Nobody really has a clue what plans Oracle had for this or what information was going to be stored in there! All we know is that it comes from the sample data provided by Oracle – so if you chose this option during installation, then you will have junk-data in your database. Those who did not take Oracle’s sample data/projects at the beginning probably won’t run into this problem.
It is noted that the table may be removed in a future release, which is a great suggestion as it is starting to cause issues with an important function of P6. Essentially what is happening is that the POBS tables are increasing in size and suddenly, you might be getting thousands of extra lines of data in your XER files. Fortunately, we have very simple fixes to manually delete or create a statement that will exclude the POBS data from your import and export operations.
SOLUTION
If you can nip it at the source of it all, then why not? Try this with your database administrator:
1. Delete all of the data from the POBS tables from the database using the following statement:
– delete from pobs;
– commit; (Oracle database only – ignore if you’ve deployed SQL)
2. Export the XER file again
Although the Oracle Database is discontinued to be offered with P6, if you are still using it, then you need to also disable some triggers and run the following statements as the schema owner:
– alter trigger rt_pobs disable;
– alter trigger rt_pobs_del disable;
Although you may have fixed the issue on your own databases, other clients/contractors/consultants you are working with may not have so their XER files will still contain POBS table data. The above solution only prevents your database from exporting POBS table data, but does not prevent the import of POBS table data from other files if they have not already been excluded from their originating databases. You will need to manually delete from the XER file:
3. ALWAYS create a backup or copy of the XER project file – mistakes happen!
4. Right click on the XER and Open With a text editor (most people will use Notepad for this)
5. Find the line: %T POBS (you can Ctrl+F to locate and highlight right away)
6. HIGHLIGHT AND DELETE the following lines until you reach the next %T:
– %T POBS
– %F (including all line content)
– %R (including all line content)
7. DO NOT HIGHLIGHT AND DELETE the next %T line and its contents, which should be “%T UDFTYPE”
8. Save the XER file
9. Re-import the updated XER file and check to see if
Depending on the size of your project, you might be deleting hundreds or thousands of lines. It is mind boggling once you get rid of these extra lines, to see the drastic reduction that takes place in the file size (even coming back down to below 1MB!).