![]() task_code in the xer) is unique and persistent it is also user-controllable. For many years the complaint has been in the opposite direction (though incorrect since Unique IDs became user-accessible in MSP.) Project's UID is unique and persistent, but as a machine-assigned, pure incremented integer it has no other value. It's kind of funny to read a complaint about lack of unique activity IDs in P6 - coming from another MSP user. They tend to be incremented from export to export as far as I can tell. The other fields you mention are export-only keys for keeping the associations among the tables within a given xer. It is also the primary key for comparing schedule versions within P6 and other tools. This is the same as the Activity ID in P6. ![]() In the Task table of the xer file, the task_code field is the unique, persistent activity identifier. The full details of these is contained in the section of the XER file under "PROJWBS". ![]() I don't know too much about MSP, but as far as I can tell the outline parent is the equivalent of the WBS codes in Primavera. Please note that if an activity is deleted then added the exact same details in as a new activity back in to the project then it will get a new ID number, but if the item is deleted then you use undo, then the original ID should be kept - deleted items are only flagged as deleted and then only fully deleted later (not sure what triggers the full delete - whether it is when logging off, or if committing changes - F10). If you are comparing the same project but from different databases then you will have to use the task_code value (or whatever is used by the table you are looking at) instead. If you are wanting to compare files generated from the same database then use the "_id" values. When receiving an XER file from a third party, if you import the XER file into your database then re-export the project & compare the 2 files, then all the id values will change (notepad++ has a compare plugin available which makes making comparisons of XER files really easy). When an xer file is sent from someone else, then during import each activity is then allocated it's own unique ID by your database to avoid the possibility of having duplicate keys & the import is based on the Activity ID entered by the user & the software runs a comparison between the XER file & the project selected to import into. The times when this number would change in the same database is if you create a reflection project & export that, as this is a full copy of the existing plan & each item is then allocated it's own unique ID. It should not make any difference how big an XER file is, these will still be the same. Any field in the exported xer file that ends with "_id" is the unique ID allocated by your database for that item & should be the same no matter how many times you export the project.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |