Такой вот вопросик возник - Можно ли внутри триггера получить информацию об том, на какую операцию он был задействован?
Делается аудитинг для операционистики и по задаче любая операция сопровождается копированием исходной инфы в другую базу или файловую группу.
И второй вопросик - Что лучше использовать для аудитинга - файловую группу или отдельную базу?

Можно ли внутри триггера получить информацию об том, на какую операцию он был задействован?
F1. RTFM.

Смотрел, не нашел.
Как _создать_ - нет проблем. Вопрос не в том, как создать соответствующий триггер, вопрос в том, как внутри триггера, созданного для Update, Insert, Delete выяснить что же именно вызвало срабатывание...
P.S. Пока просто разнес триггеры по операциям.

по наличию содержимого в таблицах inserted/deleted.

Это - лишний скан, хотя и не долгий. Я искал какую-нибудь системную переменную @@что-то...
Пока оставил разнесенными - все одно они генерируются - объем и количество меня не поджимают.

а других способов и нет

Тогда - в топку. Бо при этом не различаются INSERT/UPDATE операции, из-за которых, собственно, и делается аудит.
Что скажешь по поводу отдельной базы или отдельной файловой группы для аудитинга. Я этим не занимался, не было необходимости, и потому не могу прийти к определенному решению. Босс говорит, что он решал такую задачу в пределах одной базы и уперся в какие-то проблемы со сложностью системы. Подозреваю, что решалось все в пределах PRIMARY-группы, что, разумеется, изначально не есть гут. Но сам склоняюсь к созданию второй файловой группы - база, по моему мнению, должна быть единой... хотя реализацию в виде отдельной базы уже сделал.

ну, если в inserted че-та есть, а в deleted нету, то, значит, INSERT... только так и различают, если лень несколько похожих триггеров городить... маленький недостаток - если ни 1 запись не изменена, то невозможно определить, какая все же операция вызвала триггер... Кстати, для аудита рекомендуют именно 3 триггера.
мне тоже больше нравится вариант в 1 базе... как-то не по себе при мысли о синхронизации юзеров и прав, пусть даже автоматизированной; а если еще про app roles подумаю, вообще тоскливо становится.
вот, кста, статейка про аудит: http://www.sql.ru/articles/mssql/2005/030701ChangesLogging.shtml
а, еще - profiler forever :D

Юзера меня мало беспокоят - не того уровня уровня аудит. Пока по крайней мере. Но все же каждая запись имеет отметину юзверя.
Роли в базе - вообще не страшно - с ними никто не возится, Роли по приложению - прописаны в таблице, аудируемой.
Спасибо за ссылку - статью посмотрел. Полезного для себя почти не получил - исключение - нашел у себя баг, который пока не проявился - по задаче за раз изменяется одна запись. Но поправить - надо будет.
Спасибки за помощь и пусть не Профайлер рулит тобой, а ты - Профайлером...

так в теле триггера ж прописано на что он срабатывает
(на какое событие)

MS SQL'овский триггер может быть _один_ на все три события. Мне же ж нужно было знать какое именно событие его вызвало, чтобы отмаркировать аудиторную запись. Решилось, как и написано выше, разнесением триггеров...