another option is to copy the project strip out what you do not want to sent then send the copied XER.
Santosh the option for do nto import can be used if there are 2 or more projects contained in ONE xer file. As you know that now a baseline can be exported with the current project. During the import maybe you only want to import the the current project and not the baseline. This is how this option is useful.
Member for
20 years 6 months
Member for20 years6 months
Submitted by Santosh Bhat on Wed, 2021-12-22 00:15
The First issue is that an XER file can contain Global data that will then be imported into the destination DB as global data. Consider examples as the best example. In your Source DB, you create a project that has activities referencing a Global Calendar. Lets call this "GLOBCAL". When you export your project to an XER file, the XER file contains references to GLOBCAL and identifies it as a Glboal Calendar.
When this XER is imported into the destination DB, then P6 will import GLOBCAL as a Global Calendar. Here's how the four options work:
Update Existing will overwrite the destination GLOBCAL with the GLOBCAL in the XER. This is an issue if for example, the XER version of GLOBCAL has different workperiods, particularly if there are other projects in the destination DB that also use the GLOBACAL calendar.
Keep Existing will ignore the GLOBCAL in the XER file, but use the GLOBCAL in the Destination DB. Again, this is an issue if the calendars are different. Note that if you select Keep Existing, and there is no existing, then it will obviously create it as a new Global Calendar
Insert New In this option, P6 will always create a new Global Calendar using the XER values. If the calendar already exists in the Destination DB, this new calendar created will be called GLOBCAL_1 and and the imported XER project(s) will be assigned to GLOBCAL_1. This does not affect existing projects and activities but can quickly make the number of calendars grow.
Do Not Import. I'm not certain how this would work in practice as if it cannot import, then the schedule you're importing will not be complete. Not a good option.
The second issue is that an XER might contain data you don't want imported, for example Activity codes, or User Defined Fields. You can to some extent modify the XER file's contents to address this. For example you can open the XER file in Notepad and simply delete the rows of values you don't want to import. BUT this is extremely dangerous to do with certain data fields. For example, Calendars, all the Calendar values in an XER file are there becuase they are being used by the projects in the XER file. Delete a Calendar, and the project won't import correctly.
And finally, any XER file only contains the values that are being used by the project(s) being exported. So for example, lets say you create an Activity code, and create 50 code values in your P6 Database. Then you have assigned these code values to your project(s), but you've only assigned 30 out of the 50 Code values so far. The Exported XER file will only contains those 30 code values, and only those 30 will be imported into the destination DB. So you don't actually get any "extra" data, only those referenced by the project.
Member for
16 years 3 monthsJohn another option is to
John
another option is to copy the project strip out what you do not want to sent then send the copied XER.
Santosh the option for do nto import can be used if there are 2 or more projects contained in ONE xer file. As you know that now a baseline can be exported with the current project. During the import maybe you only want to import the the current project and not the baseline. This is how this option is useful.
Member for
20 years 6 monthsJohn. There are two seperate
John.
There are two seperate issues you've identified.
The First issue is that an XER file can contain Global data that will then be imported into the destination DB as global data. Consider examples as the best example. In your Source DB, you create a project that has activities referencing a Global Calendar. Lets call this "GLOBCAL". When you export your project to an XER file, the XER file contains references to GLOBCAL and identifies it as a Glboal Calendar.
When this XER is imported into the destination DB, then P6 will import GLOBCAL as a Global Calendar. Here's how the four options work:
The second issue is that an XER might contain data you don't want imported, for example Activity codes, or User Defined Fields. You can to some extent modify the XER file's contents to address this. For example you can open the XER file in Notepad and simply delete the rows of values you don't want to import. BUT this is extremely dangerous to do with certain data fields. For example, Calendars, all the Calendar values in an XER file are there becuase they are being used by the projects in the XER file. Delete a Calendar, and the project won't import correctly.
And finally, any XER file only contains the values that are being used by the project(s) being exported. So for example, lets say you create an Activity code, and create 50 code values in your P6 Database. Then you have assigned these code values to your project(s), but you've only assigned 30 out of the 50 Code values so far. The Exported XER file will only contains those 30 code values, and only those 30 will be imported into the destination DB. So you don't actually get any "extra" data, only those referenced by the project.