That using triggers for Audit is OK and also that you should be careful with using trigger and MERGE operation.

Naomi, I'm curious if you can clarify the exact issue.

Also...have you actually created two tables with the same structure but different data, performed a MERGE, and see what happens if the trigger supports all three operations?

Remember that, with the MERGE, you can have "when matched then update, when not matched then insert" sections, and that a single trigger on both INSERT and UPDATE operations will fire twice.

(I realize it's his post and not yours, but Dmitri's explanation on the MSDN forum is very poorly explained and his conclusion is faulty. Actually part of what he's saying is right, but for the wrong reason...his code won't work, because he needs to place a "else if exists (select * from deleted)" at the end. So I don't understand why you'd mark/propose that on MSDN as the solution)

Now, back to Pete's issue....I thought he was only interested in tracking changes...obviously, if he wants new addresses in his history table, he can either add an INSERT trigger that only reads inserted, or he can modify the update trigger to support inserts as well. But the bottom line...if someone had insert and update triggers correctly written in the past, when using INSERT and UPDATE statements - moving to a MERGE shouldn't change things.

(Finally...INSTEAD OF triggers can cause issues with MERGE, but that's way beyond the scope of this).