David,

I don't recommend turning off the trigger ... it would most likely raise hell with the accounting application. Not a good idea.

Also, a question ... are you running your tests on the actual server? Or are you doing this on a copy of the database running on your own computer? Most servers have beefed up processors and lotsa RAM and can perform their operations much faster than your own computer would. So, before you make any judgements on the speed of the update, you'd need to actually run it on the server and not on your own computer. If you're already doing that, then ... oh well, I guess we'd need to come up with some other ideas ...

~~Bonnie


>What would be the best way to temporarily turn off the processing done by a sql server trigger, depending on the context, i.e. what code triggered it to fire. I this particular case I am working with a pre-existing database that already has the trigger code written. The trigger on the table 'sostrs' updates rows in 3 other tables. But, in the program module I added, the trigger code is not relevant to the update I am performing. (Although performing the code does not cause any problems in turns of the state of the database - the only problem is that the trigger is slowing down the execution of my code. In fact it turns out that the execution of the trigger is dramatically slowing down my update code. I discussed this in a separate thread (thread #681374).
>
>It would be easy enough to update a column in a table created specifically for this purpose with some flag that indicates that the update code in my routine is about to run, and then change the trigger so that it just returns without doing any processing, if the flag is set, and then unsets the flag when the updates are done. But in a multiuser situation, there is the chance that others might attempt an update at the time the flag was set, and then the code that is necesssary for their case would not run.
>
>Any suggestions on how to handle this would be appreciated.
>