Hi,

Trigger A on table B is called and runs the statements.

One of the statements updates table B.

Can I disable trigger A before this statement? Will it not stop the current trigger processing?

Mike


Nasty case of recursion you have there.

Look at DISABLE TRIGGERS in the OLH.

Roy Lambert

Hi Roy,

Which information in the online help are you referring to?

Would using a seperate procedure including disabling triggers for these statements be better?

Or moving the statements to a different trigger?

Mike

Either the pdf manual - search for DISABLE TRIGGERS or the help in EDBManager.



Roy Lambert

Mike


Ideally you need to understand why the recursion is there and stomp on it. Recursion is a great tool in a limited number of circumstance but from the very little information provided it seems as though this one will bite you.

Tty mapping the system flow and see if it can be avoided.

Roy Lambert

Thanks Roy.

Will check it out.

Mike,

<, Trigger A on table B is called and runs the statements.

One of the statements updates table B.

Can I disable trigger A before this statement? Will it not stop the current trigger processing?
>>

The short answer is yes, but make sure to use a BEGIN..FINALLY block to restore the triggers, or you'll have a problem on your hands.

Also, for performance purposes, if you're doing any querying or calling other procedures/functions in the triggers, look into using the statement/procedure caching in EDB 2.28:

https://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=Buffering_Caching

"Per-Session SQL Statement and Function/Procedure Caching"

https://www.elevatesoft.com/manual?action=viewprop&id=edb2&product=rsdelphiwin32&version=10T&comp=TEDBSession&prop=SQLStmtCacheSize

https://www.elevatesoft.com/manual?action=viewprop&id=edb2&product=rsdelphiwin32&version=10T&comp=TEDBSession&prop=FuncProcCacheSize

These properties can seriously improve performance in such cases (and especially with recursion).

Tim Young
Elevate Software
www.elevatesoft.com