Jeff Moden (4/25/2014)
Actually, while I'm here...If I'm reading the code correctly, the code has a bit of a flaw in it that you might want to consider. If someone inserts, updates, or deletes more than 1 row in the same insert, update, or delete, what do you want to be contained in the email? I suspect it will be that you want more than 1 row?
I'm pretty sure the OP was basing everything on the idea that all inserts, updates, and deletes were single row. Certainly Lowell's suggestion on 11 April last year handled multiple rows (including serialization using XML) and my post on April 15 last year (at 8:17 PM) specifically pointed out the multiple row issue and provided code that handled it with plain text serialization, but the OP payed no attention to that aspect of those posts. I'd forgotten that the OP had not adopted anything to handle multiple rows, hence my not very helpful response to dba.sql29.
Both statements in this part of the code
SELECT @ConfigSetID_Ins = i.ConfigSetID, @Name = i.Name, @Version = .[Version],
@Timestamp = i.[Timestamp]
from inserted i --join ConfigSet C on I.ConfigSetID = C.ConfigSetID
SELECT @ConfigSetID_Del = d.ConfigSetID, @Name = d.Name, @Version = [d].[Version],
@Timestamp = d.[Timestamp]
from deleted d-- join ConfigSet C on d.ConfigSetID = C.ConfigSetID
will fail if more than one row is updated, inserted, or deleted so that may be where dba.sql29 is finding a problem.
Tom