Ironically, that's what I'd 'like' to do...I have a generic log stored proc that is maybe 20 lines of code at the most, and it's called from about 4 different update triggers [representing four production tables that users edit throughout the day]. So I personally don't see the harm in repeating 20 lines of code in 4 update triggers...having direct access to the INSERTED and DELETED tables will certainly cut down on a few lines of code in the trigger.

Unfortunately, our DBA doesn't realize that T-SQL is different from development languages in that trying to break things into multiple steps/procs [to reduce amount of code] winds up requiring more code and more complexity.

Our app is a financial app with some of the strictest auditing requirements I've ever seen.

Kevin