This is a fairly common error message if inside your event you are trying to perform a query or update on the same object that fired the event. In order to make a recommendation for a workaround I would need to see the reference to PURCHASE_ORDER_LINE_TAB. Can you please show the code for your event action.

Hi @ZTC ZTC JGOTA 

This is a common issue, have a read through this - it should help:

Cheers,

Pete

Hi @ZTC ZTC JGOTA, simple way to get rid mutating issue is using  PRAGMA AUTONOMOUS_TRANSACTION; keyword right after where your SQL statement declaration and test it if you still getting an error. Sometimes adding this won't help you, in that case you have to send one transaction via background job to fulfill your requirement. 

@EntShehaM @ZTC ZTC JGOTA If you are using PRAGMA AUTONOMOUS TRANSACTION in a block, be informed that specific block would operate as an an independent transaction block separate from the originated transaction. That means, even though the originating transaction fails, this block can commit by its own. You have to write your logic keeping this behavior in mind, otherwise there could be data inconsistencies resulted.

I think the feedback is great, but because you are just starting and do not have a lot of experience in resolving this issue I think it would be beneficial to post your event action code here so the community can give you some direct code suggestions to resolve your issue.

Once we see the code and can offer a workaround we can explain what method was used and why.

Could you please post an example of PRAGMA AUTONOMOUS_TRANSACTION?

What I did to fix these issues was:

1- Created a background job that will carry the data using the ATTR to a custom PLSQL - API procedure and the procedure will call the IFS Mail to send the email

@ZTC ZTC JGOTA 
answering your previous question, you can find a good example of using PRAGMA AUTONOMOUS TRANSACTION in Transaction_SYS.Log_Progress_Info method.
 

Transaction_SYS.Log_Progress_Info is something which is used inside application logic that is executed in background jobs (i.e. in Database task PLSQL methods). So even if the main transaction which executes the application logic fails & rolls back, the logging task commits separately. (so that it could be traced until what point the job executed & so on)

I believe, the solution you have implemented using posting a background job for this purpose is a much better solution. The background job would be committed to the relevant table (TRANSACTION_SYS_LOCAL_TAB) only if the main transaction commits, so that minimum chance of data inconsistancies.

Many IFS objects also have a History table which will be filled with information. In that case, one workaround is to trigger on a post in that table.

In above example I would have tried a trigger on PURCHASE_ORDER_LINE_HIST_TAB instead. 

The benefits are several compared to AUTONOMOUS TRANSACTION and other workarounds.

It often works, but you can of course not solve everything and all IFS objects doesn’t have a corresponding History table or is not posting a record for the insert/update/delete you are interested in.