Another thing to watch out for: sending email from inside a trigger is generally considered a bad idea. Ideally, you want your triggers to execute quickly and stop holding up transaction completion. Waiting for a remote process like sending mail can result in unacceptable delays. Think how long that trigger will run if you inserted 1,000 rows into the table. Or 10,000.

A common way around this problem is to insert the values for @Email (recipients), @body, @subject, etc. into a table, with a DATETIME column called, say, EmailProcessed, with a default value of NULL. Then you can create an Agent job to query for all NULL rows, send out the emails, and update the table with the current datetime.

In other words, send the emails asynchronously.

This also gives you the added benefit of having a log table of email delivery, which may help you in other ways. If you are sure you don't need that confirmation persisted, you can simply delete the row after sending and dispense with the DATETIME.

Rich