since this ia true realtional database every thing is based on a record number. Think of it as a row in excel and all of the data associated with that row relates to the record number. The only thing that makes it unique is the wbs and activity id
The task_id field in the Database is the unique reference number that the activity is based on & is used to link everything apart from the Baseline Data.
As the baseline plan is saved as a separate plan within the database (but not shown in the Project List), each activity has it's own task_id generated, as there cannot be duplicates within the database (Unique ID).
The task_id value will change if you were to export from one database & import into a new database, so Primavera uses the Activity ID to update any existing items when importing an update into a project.
When a baseline is generated (Maintain Baselines -> Add), a full copy of the existing project is created internally to the database - with all Project specific items being allocated new _id values. Global data would retain the existing _id values (e.g. Resources) and would be allocated against the Baseline plan.
There is no way to change this behaviour within Primavera (or I would be very suprised if there was without causing databse corruption).
Please note that the task_id values (or any _id value) are also not used when Importing projects (from XER Files). Primavera will use the task_code value & perform a lookup on that value to see if it exists wihin the project being imported into - this is also why it is not a good idea to allow Duplicate resources against activities, as Primavera looks for the Task Code & Resource Code and if found will overwrite the existing value unless the settings are set to add new values instead.
The _id values are unique for that activity only in the Primavera Database that the Project was exported from & will be changed on import to a new database, or if imported as another project in the same database.
Not a solution to your problem, but hope it helps anyway.
Member for
16 years 3 monthssince this ia true realtional
since this ia true realtional database every thing is based on a record number. Think of it as a row in excel and all of the data associated with that row relates to the record number. The only thing that makes it unique is the wbs and activity id
Member for
8 years 1 monthMartin,The task_id field in
Martin,
The task_id field in the Database is the unique reference number that the activity is based on & is used to link everything apart from the Baseline Data.
As the baseline plan is saved as a separate plan within the database (but not shown in the Project List), each activity has it's own task_id generated, as there cannot be duplicates within the database (Unique ID).
The task_id value will change if you were to export from one database & import into a new database, so Primavera uses the Activity ID to update any existing items when importing an update into a project.
When a baseline is generated (Maintain Baselines -> Add), a full copy of the existing project is created internally to the database - with all Project specific items being allocated new _id values. Global data would retain the existing _id values (e.g. Resources) and would be allocated against the Baseline plan.
There is no way to change this behaviour within Primavera (or I would be very suprised if there was without causing databse corruption).
Please note that the task_id values (or any _id value) are also not used when Importing projects (from XER Files). Primavera will use the task_code value & perform a lookup on that value to see if it exists wihin the project being imported into - this is also why it is not a good idea to allow Duplicate resources against activities, as Primavera looks for the Task Code & Resource Code and if found will overwrite the existing value unless the settings are set to add new values instead.
The _id values are unique for that activity only in the Primavera Database that the Project was exported from & will be changed on import to a new database, or if imported as another project in the same database.
Not a solution to your problem, but hope it helps anyway.
Steven