Thanks to all for your input! I have new information that I intend to utilize.

Bob Archer had recommended the site: http://www.sql-server-performance.com
(in another post)

It was very helpful. In a section on optimizing triggers they talk about the use of the update() or columns_updated() function in transact-sql - which can reduce the amount of work done by an update trigger. I think I'm going to try to implement it.

Here is a snippet from the recommendation:

The code that is included inside an UPDATE trigger runs every time its related table is updated. In most UPDATE triggers, the code in the trigger affects only certain columns, not all of them. Because of this, it would be pointless (and a waste of SQL Server resources) to run all of the code in the trigger if the column or columns you are interested in have not been updated. In other words, even if a column you are not interested in is updated, the UPDATE trigger will fire and run its code.

To help reduce the unnecessary running of code in an UPDATE trigger, you can take advantage one of two different functions: UPDATE() (available in SQL Server 2000) or COLUMNS_UPDATED() (available in SQL Server 7.0 and 2000).

Both functions can be used to test to see if a particular column you are interested in has changed or not. Because of this, you can write code in your trigger to only run if the column you are interested in has changed, otherwise you can prevent the code from running if the column you are interested in has not changed. This can reduce the amount of work the trigger needs to do, boosting overall performance of your database.

The UPDATE() function is used to check only one column at a time. The COLUMNS_UPDATED() function can be used to check multiple columns at a time. [ 7.0, 2000] Added 5-29-2001






>>AKAIK there's no elegent way to prevent the trigger from firing, precisely because other users can access it at the same time. The brute force approach would be to drop the trigger, perform the update, then recreate the trigger. You'd have to lock the table to prevent other users from attempting updates at the same time.
>>
>>This is a pretty drastic approach, as you can imagine, and best saved for after-hours processing if possible.
>
>How about if SQL-DMO is installed, set the trigger's enabled property to .F., make your update, then set it back to .T.? As you said, however, this is best done after-hours.