pc_work_social primary key violation in pega
We have more than one application, we do both migration upgrade, currently in the process of migration data AWS cloud to Pega cloud. We are getting primary key violation when we migrating data into pc_work_social since primary key of pc_work_social table (pzinskey) contains numbers with M- prefix. (Not contains class and timestamp) Both source and destination has same primary and different values for other columns.
Eg. M-1 record contains both source and the target for pzinskey but other columns contain different values.
I wanted to know do we have any possible work around to keep both record in target.
Thanks
Pegasystems Inc.
IN
It is a tedious process and risky as well. We need to write an activity to modify the id(preferably in small application) and in all the related tables as well(worklist,workbasket,attachment,history,etc).
Updated: 20 Nov 2020 0:41 EST
EvonSys
LK
Thanks Ravik2.
Do you have any idea about how it connects to Cases etc. if we write something(Activity) to change this we have to get an idea of connections to the pc_work_social (ER). We are not aware of entity relations since this is an OOTB table.
We are in migration of multiple instance into one instance. Therefore we need to do this.
Thanks,
Jayantha.
Pegasystems Inc.
IN
Pulse table (pc_work_social) has association with multiple tables so updating pulse ID will requires to updating all the associated tables and it might be very tricky and not recommended. Attached the PDF related to all the pulse associations.
Note : In the ER diagram, wherever pyContext is mentioned in pulse, it can be considered as pyIndirectObjectID column in pc_work_Social table
Case-Pulse relationship can be ignored as case doesn't hold any property related to pulse. pyIndirectObjectID column in pc_work_Social table holds the case inskey so updating pulse id will not have any impact on case relationship
Please refer 'Pulse ER.jpg' file for relation between pc_Work_social and pr_data_referencedusers table which is missed in PDF attached
Updated: 2 Dec 2020 5:14 EST
EvonSys
LK
Thanks for the information shared.
I have analyzed, tables on client 7.x production db environment. There I have found few deviations from information which we have got from pega.
1. Some of the fields(columns) in ER document which has been given by pega are not there in the client’s 7.x production DB tables. (Eg. pyMessage, pycontext(pzinskey of case) in pc_work_social table and pyAttachStream , pyFileName, pyNote (Complete pulse message) in pc_data_workattach.
2. pyID (M-11) or pzinskey(PEGASOCIAL M-11) in pc_work_social not shared in other related tables. (pyID is the field getting duplicate when we tried to migrate from multiple DB environments)
Appreciate if you could clarify this as well.
Thanks in advance.