Inventory Part Revision on Product Structure Revision
Hi,
We use the revisions of Inventory Parts to keep the revision our customer is on (Field ENG_REVISION), so when we do an internal revision of our Product Structure we would like to keep the customer revision the same.
For this I started out doing a custom event to copy the ENG_REVISION field from the previous revision, but I am hitting the mutating error.
Below is the code I am using for now, and attached is the event ID and all its parameters. I have read that there are workarounds if trying to use background jobs, but don’t exactly know and understand how to go about doing so.
CURSOR get_last_revision IS SELECT OBJID, OBJVERSION, ENG_REVISION, ENG_REVISION_DESC FROM IFSAPP.PART_REVISION WHERE CONTRACT='&NEW:CONTRACT' AND PART_NO='&NEW:PART_NO' AND ENG_CHG_LEVEL='&NEW:ENG_CHG_LEVEL'-1;
OPEN get_last_revision; FETCH get_last_revision INTO p1_, p2_, new_Eng_Revision, new_Eng_Revision_Desc; CLOSE get_last_revision;
I’m assuming by the mutating error you are referring to the ORA-04091 error. In that case, the possible cause would be that you are trying to both select and update the IFSAPP.PART_REVISION table in a row level trigger.
I’m assuming by the mutating error you are referring to the ORA-04091 error. In that case, the possible cause would be that you are trying to both select and update the IFSAPP.PART_REVISION table in a row level trigger.
Yes, you are correct, however the error is on top of a Custom Event in IFS, as I am not doing anything directly on the Oracle database.
This is why I ask, if there is a workaround within IFS?
Thanks, Mendes
Hi @carlosfmendes ,
I believe the below post might contain the answer you are looking for:
Can you try your custom event again by utilizing PRAGMA AUTONOMOUS_TRANSACTION; ?
Regards, Malindu
Hi @carlosfmendes ,
I believe the below post might contain the answer you are looking for:
Can you try your custom event again by utilizing PRAGMA AUTONOMOUS_TRANSACTION; ?
Regards, Malindu
If I understand correctly, this makes an autonomous and asynchronous transaction, correct? I can see this might work, as the trigger is AFTER creation, and not on any CHANGE or REMOVAL.
So I need the new row created, to then update the fields on this newly created row.
However at the moment, I have the problem that I need to get the OBJID and OBJVERSION of the recently created row at the beginning of the custom event, however the SELECT statement returns no OBJID and OBJVERSION, so I assume it is not yet created, even though the custom event is for AFTER creation.
Does this have anything to do with this change, to do put PRAGMA AUTONOMOUS_TRANSACTION?
Hi @carlosfmendes ,
You can make you sql into a string and the execute it as a background job.