Мне нужен способ проверки, когда кто-то пытается ВКЛЮЧИТЬ или ВЫКЛЮЧИТЬ триггер в нашей базе данных. Альтернативный вариант триггера DDL отлично работает, но только при условии, что пользователь использует оператор
ALTER TABLE <tableName> ENABLE TRIGGER <triggerName>
OR
ALTER TABLE <tableName> DISABLE TRIGGER <triggerName>
. Из того, что я определил, метод DDL становится бесполезным, если пользователь выполняет следующие инструкции, обходящие команду ALTER:
DISABLE TRIGGER <triggerName> ON <tableName>
ENABLE TRIGGER <triggerName> ON <tableName>
У меня было несколько мыслей по поводу записи этих событий, ни одна из них не работает. Один из них заключался в том, что если бы я мог получить доступ к таблице, лежащей в основе представления sys.triggers, я мог бы разместить триггер вставки / обновления в этой таблице и отфильтровать имя триггера для получения аудита; но я подозреваю, что это могло бы привести к бесконечной рекурсии, даже если бы это было возможно.
Есть ли у кого-нибудь здесь возможные предложения по альтернативным решениям этой проблемы? Я не понимаю, почему MS позволяет расширенным версиям отчетов выходить за рамки аудита. То есть одитинг простейшими методами; использование профилировщика SQL для этого не требует дополнительных затрат.