Вообще-то хелп придумали не просто так - его читать иногда надо. Почитайте в про триггера вообще и про таблицы inserted и deleted.

А Вы в курсе, что в MS SQL триггер на update работает с двумя таблицами - inserted и deleted ? А таблицы updated или ей подобной не существует ?

Бывает Когда мне пришлось с Oracle и Interbase переходить на MSSQL, то организация триггеров мне показалась просто дикой. И сейчас это ощущение иногда возвращается...

1. В Оракле есть триггера для уровня строки, а есть для уровня операции в целом. Пример, когда это удобно: выполнить некую stored proc для _каждой_ обновляемой записи. Как это можно сделать в MS SQL, кроме как организовав курсор по таблице inserted ? Да, в 2000 это можно в некоторой степени сымитировать функциями, но это будет _очень_ неудобно, потому что использование многих полезных фич в функциях запрещено по сравнению с процедурами. А до 2000 что было делать ?
2. Разделение триггеров BEFORE/AFTER. Без комментариев.
3. Если я хочу в триггере insert/update вносить изменения в _ту_же_самую_ запись, то приходится писать что-то вроде update mytable set mytable.field1 = <бла-бла> from mytable, inserted where mytable.id = inserted.id По-моему, это маразм. Я хочу просто написать new.field1 = <бла-бла> (синтаксис примерно interbase'овский). Все!!! И не говорите мне, что обновления той же самой записи - дело вредное и ненужное. Типичный случай - поле change_time, куда заносится время, когда запись менялась.

Пока все. Ежели что вспомню, допишу... Правда, Оракл забываться стал - давненько мы не брали в руки шашек

В MSSQL нет триггеров уровня строки, только для операции целиком.
Если написать update mytable set ... where ... , где условие where затрагивает несколько строк, то триггер on update сработает ОДИН раз и в таблицы inserted и deleted будут помещены те строки, которые обновлялись. С ними работа почти как с обычными таблицами - можно select'ы делать, можно курсоры и т.д.