David,

>>So I guess I have to weigh the benefits of speeding up the table update against requiring exclusive use.<

Looks like you're stuck between a rock and a hard place ... oh well, it seems there's always these types of decisions to be made. Good luck with it!

>>>>http://www.sql-server-performance.com
and then I did a search on cursors and found that sql server cursors are indeed problematic:<

Yeah, it looks like a good site ... I bookmarked it. FWIW, I don't think we use sql cursors in *any* of our SP's (or triggers) ... we use temporary tables. I guess this must be the reason why! <g>

~~Bonnie



>Bonnie,
>
>The operation requires that the user load the sales order line item file in its entirety (86k rows) down from the server to a local table buffered view then start making miscellaneous updates to the line item file in the buffered view. When they hit save the the tableupdate will be updating many many rows. For each row update the trigger will fire. So even though the whole operation takes a long time, with a portion of the time being related to 'system i/o time' and a portion just related to the review/analysis work the user does with the data on the screen, it will still be beneficial to reduce the amount of time required for the actual table updating. So I guess I have to weigh the benefits of speeding up the table update against requiring exclusive use.
>
>And by the way, Bob Archer recommended a great site:
>
>http://www.sql-server-performance.com
>
>and then I did a search on cursors and found that sql server cursors are indeed problematic:
>
>http://www.sql-server-performance.com/cursors.asp
>
>So when I have the time I will see what I can do improve the trigger in light of the information at this link.
>
>
>Thanks for your help!
>
>