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