Primavera is a relational database therefore as in ANY database each item has a unique record number. In this case it is the activity id number in the schedule that has a unique record number associated with it. Since the activity id has a unique record number everything that is assocaited with the activity id always references back to the activity id number becasue without and activity id number you have NOTHING.
If you use the xer file parser and open an xer file that way you wil see that the controlling record number in the database has a field name of TASK_ID and that the activty id number has a field name of TASK_CODE
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.
It should not make any difference how big an XER file is, these will still be the same.
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.
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.
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).
If you are wanting to compare files generated from the same database then use the "_id" values.
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.
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).
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. The full details of these is contained in the section of the XER file under "PROJWBS".
Well I'm reconsidering my ealier remarks. I get identical IDs even when repeatedly exporting the same schedule of 4000+ activities, so its not a question of size or complexity.
After reviewing a number of xer and xml files (mostly exported by others and shared with me), I'm now convinced that the exported IDs are the actual record identifiers in the database tables. If a project is duplicated in the database (which seems pretty common for standalone and SME users) then all the project-specific IDs are incremented. That's typically what I've seen. (The global resource and calendar IDs are NOT incremented, since they are not duplicated.)
So essentially, these IDs seem unique and persistent for specific records within a specific database. They are not unique for a project schedule that is exported/imported between databases.
When I test with a small, test project, the task_id's keep persistent between exports.
The problem with non-persistent task_id's is with a real, big XER file.
Do you know if there is a specific pattern or criteria for changing those values? You mentioned that they tend to be incremented from export to export.
If you mean "outline parent," no, there's no such thing outside of MSP as far as I know. There are a lot of "parent" references in XER files, but all of these have do do with hierarchical coding, not summary tasks.
Another problem (for me) of the task_code field is that "parent tasks" (this concept is valid in MSP, don't know if it is in Primavera) don't have one.
Without doubt there is a unique ID key for each activity in the P6 database, but it doesn't get exported with XER. I haven't looked at enough xml export files to know if it's in there, but I doubt it. You could probably get at it through a direct query (SQL), but I'm not sure why you'd want to - for most purposes it would be even less useful than MSP's UID in my opinion.
IMO, your reliance on the inability of users to accidentally change UID in MSP is misplaced. I've reviewed MSP schedules where hundreds of UIDs were unintentionally changed by user actions. The solution is rigid control protocols (just like in P6). Changing an Activity ID in P6 requires an explicit intention to do so.
In the Task table of the xer file, the task_code field is the unique, persistent activity identifier. This is the same as the Activity ID in P6. It is also the primary key for comparing schedule versions within P6 and other tools. The other fields you mention are export-only keys for keeping the associations among the tables within a given xer. They tend to be incremented from export to export as far as I can tell.
It's kind of funny to read a complaint about lack of unique activity IDs in P6 - coming from another MSP user. 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. P6's activity ID (i.e. task_code in the xer) is unique and persistent; it is also user-controllable. Many P6 users add intelligent attributes to Activity IDs to assist in organizing and analysing the schedule.
Member for
16 years 3 monthsPrimavera is a relational
Primavera is a relational database therefore as in ANY database each item has a unique record number. In this case it is the activity id number in the schedule that has a unique record number associated with it. Since the activity id has a unique record number everything that is assocaited with the activity id always references back to the activity id number becasue without and activity id number you have NOTHING.
If you use the xer file parser and open an xer file that way you wil see that the controlling record number in the database has a field name of TASK_ID and that the activty id number has a field name of TASK_CODE
Member for
8 years 1 monthAlvaro,Any field in the
Alvaro,
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.
It should not make any difference how big an XER file is, these will still be the same.
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.
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.
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).
If you are wanting to compare files generated from the same database then use the "_id" values.
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.
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).
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. The full details of these is contained in the section of the XER file under "PROJWBS".
Hope this helps.
Member for
18 years 11 monthsAlvaro,Well I'm reconsidering
Alvaro,
Well I'm reconsidering my ealier remarks. I get identical IDs even when repeatedly exporting the same schedule of 4000+ activities, so its not a question of size or complexity.
After reviewing a number of xer and xml files (mostly exported by others and shared with me), I'm now convinced that the exported IDs are the actual record identifiers in the database tables. If a project is duplicated in the database (which seems pretty common for standalone and SME users) then all the project-specific IDs are incremented. That's typically what I've seen. (The global resource and calendar IDs are NOT incremented, since they are not duplicated.)
So essentially, these IDs seem unique and persistent for specific records within a specific database. They are not unique for a project schedule that is exported/imported between databases.
Just curious, what are you up to?
Member for
7 years 7 monthsWhen I test with a small,
When I test with a small, test project, the task_id's keep persistent between exports.
The problem with non-persistent task_id's is with a real, big XER file.
Do you know if there is a specific pattern or criteria for changing those values? You mentioned that they tend to be incremented from export to export.
Member for
18 years 11 monthsIf you mean "outline parent,"
If you mean "outline parent," no, there's no such thing outside of MSP as far as I know. There are a lot of "parent" references in XER files, but all of these have do do with hierarchical coding, not summary tasks.
Member for
7 years 7 monthsAnother problem (for me) of
Another problem (for me) of the task_code field is that "parent tasks" (this concept is valid in MSP, don't know if it is in Primavera) don't have one.
Member for
18 years 11 monthsAlvaro,Without doubt there is
Alvaro,
Member for
7 years 7 months(I wanted the message to be
(I wanted the message to be below)
Member for
7 years 7 monthsHi Tom. Thanks for your
Hi Tom. Thanks for your answer!
Effectively the task_code is useful for my purpose.
The only thing that I miss from MSP UID's is that the user cannot accidentaly change the UID.
But the task_code can be edited in the Primavera interface.
Is there another field that cannot be changed by the user in the interface?
Member for
18 years 11 monthsAlvero,In the Task table of
Alvero,
In the Task table of the xer file, the task_code field is the unique, persistent activity identifier. This is the same as the Activity ID in P6. It is also the primary key for comparing schedule versions within P6 and other tools. The other fields you mention are export-only keys for keeping the associations among the tables within a given xer. They tend to be incremented from export to export as far as I can tell.
It's kind of funny to read a complaint about lack of unique activity IDs in P6 - coming from another MSP user. 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. P6's activity ID (i.e. task_code in the xer) is unique and persistent; it is also user-controllable. Many P6 users add intelligent attributes to Activity IDs to assist in organizing and analysing the schedule.
Good luck, tom