APAR status
Closed as program error.
Error description
CMP/OMF IR-REG FOR LAST_OBJECT_ID NOT UPDATED Customer found a problem that seems to be linked to previous cas e (23716,660,706) SCENARIO : You need to have 2 users connected to the DB on 2 PCs to reproduce the problem! Below the script: 1- Connect USER1 and USER2 on 2 different machines WITH USER1: 2- Create a Part A, link it to toto.CATPart and let it NEW 3- Disconnect USER1 and reconnect 4- Create a Part B which references the same file as Part A (toto.CATPart) => You get an error 00947 because file is already referenced by Part A 5- Cancel creation of Part B 6- Create a Part C WITH USER2: 7- Create a Part D 8- Create a Part E => YOU GET AN ERROR 00055 (element already exists) Add Info from customer: Create Part E follows the same mecanism as creating a new version of object (Check Out). On Check Out there are no error message but a rollback is performed, so the Check In data becomes locked. ANALYSIS OF THE PROBLEM BY CUSTOMER: Explanation of the bug, step by step: 2- User1 books a sequence of 20 OBJECT_IDs and use the first one (1 -> 20) => LAST_OBJECT_ID is updated (21) 4- Deleting only the file and not the file catalog causes the bug described below 5- When creating PartB, SmarTeam books a new sequence of 20 OBJECT_IDs and use the first one (21) but doesn't create the object (21 -> 40) => LAST_OBJECT_ID is not updated!!! 6- When creating PartC, SmarTeam uses the next OBJECT_ID booked (22) 7- When User2 creates PartD, he books a sequence of OBJECT_ID starting from LAST_OBJECT_ID not updated (21) and is able to create the object => This OBJECT_ID has not been already used because PartB was not created 8- When User2 creates PartE, he get the next OBJECT_ID (22) but object is not created => This OBJECT_ID has been already used by PartC creation, SmarTeam cannot create twice : Err 00055 The problem is that 2 users can share a same sequence if one of them get errors because of referenced objects !!! This problem is appearing often and is linked to the Check Out problem : - Michelin Clonage application is generating lots of objects which can be already referenced, if user doesn't really care The check out problem (23716,660,706) is linked to this scenario because on check out operation OBJECT_ID is attributed in the same way CONCLUSION : Michelin wants that LAST_OBJECT_ID table to be updated even if there are problems on the creation of an object. Additional information from customer ------------------------------------ - The information about the SmarTeam level V5R19 SP03 HF010. - The customer's workaround information: "1. No workaound possible because we cannot follow each user. 2. Delete manually the trace in the database and restart the operation." - The customer's fix expectation and justification: "It is a strong regression from SmarTeam V5R19. The bug really alterates the consistency of the new SmarTeam version and generates lot of troubles for users: - X objects creation forbidden because of duplicate message (no value) - 50 objects locked in 3 weeks We want a correction in a HotFix of SmarTeam V5R19 SP03." WORKAROUD FOUND AND SENT TO CUSTOMER. After USER 2 has Error No: 00055 The item already exists in the system. Adding item 'Lad1_CATPRT-780668 a.00' caused a duplicate value error in 'CATIA Part'. WORKAROUND: - He clicks on OK on this error message and has returned to the profile card were he was tried to add E CATIA Part - He CLICKS ONE MORE TIME ON OK ON THE SAME PROFILE CARD AND THE E CATIA PART IS CREATED and with same ID as ??780668?? that was not created before in the first attempt - The workaround contents TWO CLICKS
Local fix
Problem summary
CMP/OMF IR-REG FOR LAST_OBJECT_ID NOT UPDATED Customer found a problem that seems to be linked to previous case (23716,660,706) SCENARIO : You need to have 2 users connected to the DB on 2 PCs to reproduce the problem! Below the script: 1- Connect USER1 and USER2 on 2 different machines WITH USER1: 2- Create a Part A, link it to toto.CATPart and let it NEW 3- Disconnect USER1 and reconnect 4- Create a Part B which references the same file as Part A (toto.CATPart) => You get an error 00947 because file is already referenced by Part A 5- Cancel creation of Part B 6- Create a Part C WITH USER2: 7- Create a Part D 8- Create a Part E => YOU GET AN ERROR 00055 (element already exists) Add Info from customer: Create Part E follows the same mecanism as creating a new version of object (Check Out). On Check Out there are no error message but a rollback is performed, so the Check In data becomes locked. ANALYSIS OF THE PROBLEM BY CUSTOMER: Explanation of the bug, step by step: 2- User1 books a sequence of 20 OBJECT_IDs and use the first one (1 -> 20) => LAST_OBJECT_ID is updated (21) 4- Deleting only the file and not the file catalog causes the bug described below 5- When creating PartB, SmarTeam books a new sequence of 20 OBJECT_IDs and use the first one (21) but doesn't create the object (21 -> 40) => LAST_OBJECT_ID is not updated!!! 6- When creating PartC, SmarTeam uses the next OBJECT_ID booked (22) 7- When User2 creates PartD, he books a sequence of OBJECT_ID starting from LAST_OBJECT_ID not updated (21) and is able to create the object => This OBJECT_ID has not been already used because PartB was not created 8- When User2 creates PartE, he get the next OBJECT_ID (22) but object is not created => This OBJECT_ID has been already used by PartC creation, SmarTeam cannot create twice : Err 00055 The problem is that 2 users can share a same sequence if one of them get errors because of referenced objects !!! This problem is appearing often and is linked to the Check Out problem : - Michelin Clonage application is generating lots of objects which can be already referenced, if user doesn't really care The check out problem (23716,660,706) is linked to this scenario because on check out operation OBJECT_ID is attributed in the same way CONCLUSION : Michelin wants that LAST_OBJECT_ID table to be updated even if there are problems on the creation of an object. Additional information from customer ------------------------------------ - The information about the SmarTeam level V5R19 SP03 HF010. - The customer's workaround information: "1. No workaound possible because we cannot follow each user. 2. Delete manually the trace in the database and restart the operation." - The customer's fix expectation and justification: "It is a strong regression from SmarTeam V5R19. The bug really alterates the consistency of the new SmarTeam version and generates lot of troubles for users: - X objects creation forbidden because of duplicate message (no value) - 50 objects locked in 3 weeks We want a correction in a HotFix of SmarTeam V5R19 SP03." WORKAROUD FOUND AND SENT TO CUSTOMER. After USER 2 has Error No: 00055 The item already exists in the system. Adding item 'Lad1_CATPRT-780668 a.00' caused a duplicate value error in 'CATIA Part'. WORKAROUND: - He clicks on OK on this error message and has returned to the profile card were he was tried to add E CATIA Part - He CLICKS ONE MORE TIME ON OK ON THE SAME PROFILE CARD AND THE E CATIA PART IS CREATED and with same ID as ??780668?? that was not created before in the first attempt - The workaround contents TWO CLICKS
Problem conclusion
NOTE THAT THIS PROBLEM WILL ALSO BE FIXED ON V5R19 SP5. Additional Closure Information: THIS PROBLEM WILL BE FIXED ON SMARTEAM VERSION 5 RELEASE 19 SP05 LEVEL. Additional Closure Information:
Temporary fix
Comments
APAR Information
APAR number
HD85107
Reported component name
SMARTEAM NT>XP
Reported component ID
569199970
Reported release
519
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2009-05-21
Closed date
2010-03-08
Last modified date
2010-03-08
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
SMARTEAM NT>XP
Fixed component ID
569199970
Applicable component levels
R519 PSN
UP
[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SS2S3T","label":"ENOVIA SmarTeam V5"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"519","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
08 March 2010