sdbeames wrote:

>
>
>If I understand your suggestion correctly, the trigger will still be
>fired for each record that is updated after the first trigger fires.
>Only 1 simple update need be performed on each subsequent record.
>
>

The view wil be fired on the update, th trigger checks for a flag value,
that will be false, then a flag on the record will be setted, the
process will be done, so the after update trigger will be fired again,
but this time the flag will be setted so the then part of the if will
not be executed, resuming, the trigger will be fired, but no process
will occurr.

>I could create a seperate table to record this event though.
>I'll probably take this approach. My aim is to minimise the size of
>an eventually very large table (multiple activities recorded for
>multiple staff for years to come).
>
>

I would go for the flag where you put the current_transaction approach,
this way you won't need to do any cleanup.

>Is it worth my suggesting the disable/enable trigger option for a
>future version? Or some sort of global variables to record flags or
>states? Or do they already exist?
>
>

Disable trigger option: What about other users ? :-)
Global Variables: I think will be a rdb$context function to get global
values, but don't know (or remember) the semantics and escope.

>Cheers,
>Steve
>
>

see you !

--

Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.7.3 - Release Date: 15/03/2005