Importing an XER Into P6 Without Polluting Your Database
Most XER imports that go wrong are not version problems. They are data problems wearing a version problem's clothes.
The error message blames the format, or the P6 release, or the database. Then somebody tries the same file on another machine and gets a different error, or no error at all and a schedule with the wrong calendars. That is the tell: the file brought something with it.
What P6 actually does when you import an XER
An XER is a text export of a P6 project, and it is not only the project. It carries the global objects the project touches: calendars, activity codes, resources and roles, project codes, UDFs, and the POBS tables. On import, P6 has to reconcile those with whatever already exists in your database.
You get three project-level choices in the import dialog. Add the project as new. Replace an existing project with the same ID. Ignore that project and import nothing. Those decide what happens to the project. They do not let you decide what happens to each calendar, each activity code, or each resource as it arrives.
That is the gap. A calendar named "5 Day" in the incoming file lands on the "5 Day" already in your database, and the values can be overwritten. An activity code with the same name but a different meaning merges silently. Duplicate values start appearing, and the projects that were already in the database pick up the change without asking anyone.
If the file came from another company, this is not hypothetical. It is what the format does by default.
The five failures that come from the file
1. Global data merges when you did not want it to
Calendars and activity codes are the usual suspects. You can see the result weeks later: a schedule that was finished shows different dates, or a report groups activities differently because a code now means something else. Nothing in the import log mentions it.
2. POBS tables bloat the file
POBS travels with the XER whether or not the receiving database needs it. When it grows large, the import slows down badly. Plan Academy documented one case where removing POBS took a file from 25 MB to 2 MB and an import from six hours to under two minutes. That is an extreme example, but the direction is normal: less POBS, faster import.
3. Version mismatch
A file exported from a newer P6 will not import into an older one. P6 handles this with an error, which is the good outcome. The bad outcome is importing a downgraded file without checking what changed on the way down. If you need to move a file to an older release, read how P6 version numbers work before you export, not after.
4. Duplicate project and activity IDs
Two databases allocate IDs independently. An incoming project that uses IDs already present in your database either collides or lands beside them, and the second case is harder to spot. You end up with two projects that look related and are not.
5. Missing or renamed calendars
A file that references a calendar your database does not have will either create it or fail, depending on the import path. Both outcomes need checking. A schedule running on a 7 day calendar it never had will look plausible and be wrong.
The pre-import strip list
Everything below is cheaper to do before the import than to unpick afterwards. How much you strip depends on why the file is arriving. A file from a partner you trust needs less work than one from a contractor you have never used.
- Global calendars. Convert the ones the project actually uses to project level, so they cannot overwrite yours.
- Global activity codes. Same treatment. If the codes mean something specific to the sender, they should stay inside the project.
- POBS tables. Remove them unless you have a reason to keep them. Nothing in normal reporting needs them.
- Risks and notes. These travel with the project and are often the most revealing part of a file from another company.
- Resource and role rates. Remove the cost data if the schedule is going into a database where those rates should not exist.
- UDFs and project codes. Check which ones arrive. They are easy to miss and they persist.
If you are sending a file rather than receiving one, the pre-share checklist covers the same ground from the other direction.
What to check after the import
Do the checking while the file is still fresh, because the trail goes cold fast.
- Open a handful of activities in the imported project and confirm the calendar each one uses.
- Check the activity code list for duplicates before anyone starts coding against it.
- Compare the project start and finish dates against the file you were sent.
- Confirm the import did not change any project that was already in the database. If you cannot confirm that, assume it did.
If pollution has already happened, the fix is to work out which globals arrived and convert or delete them at the source. The global to project conversion page covers that.
Why this is hard to do by hand
The manual route exists, and it is honest work: open the XER in a text editor, find the POBS block, delete it, hope you found all of it. For cost data, the same idea applies table by table. It works if the file is small and you do it rarely.
ScheduleCleaner does the strip list as a step before the import. You pick the categories to remove or convert, the file is written as a new copy, and the original stays untouched. Calendars and activity codes move from global to project level, POBS and risks come out, rates and costs come out if you asked for that. The file you import is the filtered one.
That is the difference between cleaning a file and repairing a database. One takes a few minutes. The other takes a week and involves explaining to people why their dates moved.
If you want to see it on one of your own files, start a free trial and run it on the next XER you receive.
Related reading
Ready to clean your next P6 schedule?
Remove, convert and anonymize sensitive data in XER and XML files before you share them.