radi8
Well Known Member
OMW checkin error after \'GET\'
I have a problem where if I create a project in DV, check out the P4101, do an Advanced GET on this from PD, and then try to check it in, I get an error stating that the for W4101E has a duplicate key for index: P4101|9|W4101E|1|68.
After doing several test iterations, I have determined that the issue is most likely with the DV7333 F98751 table indexes.
Here is why:
Both PD7333 and JD7333 F98751 table show that there are 2 entries for the index in question (P4101|9|W4101E|1|68)
According to the table design, the primary keys are: FSOBNM, FSRCRDTP, FSGNCID2, FSWEVENT, FSGNCID3, and FSFMNM
In PD733 and JD7333, these entries (for these keys) are:
P4101, 68, 9, 49, 1, 10, W4101E - UNIQUE
P4101, 68, 9, 49, 1, 15, W4101E - UNIQUE
When I try to push these into DV7333, it fails. It seems as though the index used in DV during checking does not use or check the FSGNCID3 index.
I re-indexed the table in DV, but still will still fail to check in the object.
All I have left to try is regenerating the F98751 table and reloading it from backup. I am not inclined to do this if there is something out there that I can change to fix this problem (ESU paper fix for example).
We are on XE/SP17.3, Any help is appreciated.
I have a problem where if I create a project in DV, check out the P4101, do an Advanced GET on this from PD, and then try to check it in, I get an error stating that the for W4101E has a duplicate key for index: P4101|9|W4101E|1|68.
After doing several test iterations, I have determined that the issue is most likely with the DV7333 F98751 table indexes.
Here is why:
Both PD7333 and JD7333 F98751 table show that there are 2 entries for the index in question (P4101|9|W4101E|1|68)
According to the table design, the primary keys are: FSOBNM, FSRCRDTP, FSGNCID2, FSWEVENT, FSGNCID3, and FSFMNM
In PD733 and JD7333, these entries (for these keys) are:
P4101, 68, 9, 49, 1, 10, W4101E - UNIQUE
P4101, 68, 9, 49, 1, 15, W4101E - UNIQUE
When I try to push these into DV7333, it fails. It seems as though the index used in DV during checking does not use or check the FSGNCID3 index.
I re-indexed the table in DV, but still will still fail to check in the object.
All I have left to try is regenerating the F98751 table and reloading it from backup. I am not inclined to do this if there is something out there that I can change to fix this problem (ESU paper fix for example).
We are on XE/SP17.3, Any help is appreciated.