Philip,
Thanks for following up on this again. When I said longer term, I should have said persistent.

Right now, my program inserts one record into the master table, a couple hundred into the detail table and several thousand records into the sub-detail table. The master and detail tables represent an object and an array of detail objects in my Delphi code. I use a generic Object.Save function and it commits after each object and detail object. The detail object saves all of its sub-details in a custom loop. Your suggestion would be helpful as it is currently configured because the context variable would survive the commit that currently happens after the detail object save. I don't think the current process is configured very efficiently. I am going to do a custom loop to insert all the objects and their details and then commit.

I will also test deactivating the trigger before the save and reactivating afterward and compare that to the leaving the trigger active and controlling what it does with a context variable. I expect it might be more efficient to not execute the trigger at all rather than execute it, do nothing, and return immediately. But it feels like the context variable approach is a little more self-documenting. If there is not much difference time-wise, I would probably use the context variable because of this. I really appreciate the suggestions that you and Vlad made. The deactivating the trigger idea is exactly what I was missing. Also, being made aware of the the context variables concept is very helpful. It is something I am going to be able to make use of many times over.

Thanks very much.

Jack

--- In firebird-support@yahoogroups.com, "unordained" <unordained_00@...> wrote:
>
> ---------- Original Message -----------
> > If there was a longer term one, it might
> > also eliminate the need for the field in the status table but I will
> > definitely make use of it as it is.
> ------- End of Original Message -------
>
> Besides USER_TRANSACTION, there's also USER_SESSION, which lasts past commit. See
> http://www.firebirdsql.org/refdocs/langrefupd20-set-context.html for details.
> Instead of trying to replace the status field with a context variable, maybe a
> table (not temporary) to store items that need refreshing would suit you better?
>
> -Philip
>


--- In firebird-support@yahoogroups.com, "unordained" <unordained_00@...> wrote:
>
> ---------- Original Message -----------
> > If there was a longer term one, it might
> > also eliminate the need for the field in the status table but I will
> > definitely make use of it as it is.
> ------- End of Original Message -------
>
> Besides USER_TRANSACTION, there's also USER_SESSION, which lasts past commit. See
> http://www.firebirdsql.org/refdocs/langrefupd20-set-context.html for details.
> Instead of trying to replace the status field with a context variable, maybe a
> table (not temporary) to store items that need refreshing would suit you better?
>
> -Philip
>