Trigger error in a call store procedure (ORA-06512)

Question

Hi all,
I have a trigger (TRLFACTSIN) that update stock when delete, insert or update a record in a sales table. Inside the trigger call a store procedure (PCALCULASTOCK2), he is the manager of calculating and update the stock .
Any idea?, Thanks
Error description:
UPDATE "ALCAR"."LFACTSIN" SET CANTIDAD = '10' WHERE ROWID = 'AAA0D9AAAAAACvdAAA'
One error saving changes to table "ALCAR"."LFACTSIN":
Row 7: ORA-04091: table ALCAR.LFACTSIN is mutating, trigger/function may not see it
ORA-06512: at "ALCAR.PCALCULASTOCK2", line 114
ORA-06512: at "ALCAR.TRLFACTSIN", line 31
ORA-04088: error during execution of trigger 'ALCAR.TRLFACTSIN'
Trigger DDL:
create or replace
Trigger trLFACTSIN
AFTER INSERT OR DELETE OR UPDATE ON LFACTSIN
for each row
Declare
darticulo varchar2(13);
resultado integer default 0;
bEjecutar boolean default True;
ofic1 char(1);
begin
if (inserting) then
darticulo := :new.cod_articulo;
ofic1 := :new.oficial;
end if;
If (deleting) Then
darticulo := :old.cod_articulo;
ofic1 := :old.oficial;
end if;
If (Updating) Then
-- En el caso que sea actualización miramos si la se modificó la cantidad
if :old.cantidad = :new.cantidad Then
darticulo := '';
bEjecutar := False;
else
darticulo := :new.cod_articulo;
ofic1 := :new.oficial;
end if;
end if;
--Ejecutamos el procedimiento almacenado para actualizar el stock en el semielaborado
If bEjecutar Then
--Comprobamos si es semielaborados
Select Count(*) into resultado from semielab Where cod_semielab = darticulo;
-- Ejecutamos el procedimiento almacenado que calcula y actualiza el stock para el semielaborado
If resultado <> 0 Then
PCALCULASTOCK2(darticulo, ofic1);
resultado:=0;
end if;
End If;
End;

Answer 1

Whilst the table with the trigger on it is in the middle of a transaction you cannot select or use DML against it. This is what Oracle calls a "mutating table". It doesn't make sense to try and use a table that is in the middle of changing.
You can use an autonomous transaction to work around this issue, but you should be careful with autonomous transactions because there are drawbacks relating to maintaining transaction consistency. Effectively it means you will be making alterations to B based on the fact that A has happened, but the transaction on B will not get rolled back if A fails at any point which could leave you with A not complete but B complete, hence the inconsistency.