SangYongASA9+MSAccess

прошу прощения - меня технические стороны
волнуют больше чем принципиальные, хотя
есть один принцип:вопросов глупых не бывает,
есть только глупые ответы...
Первый способ - отключить выполнение триггеров посредством SET TEMPORARY OPTION.

Второй способ - в WHEN триггера вставить проверку существования глобальной переменной VarExists('@@DenyTrigger') = 0. Тогда, когда нужно запретить выполнение триггера, будет достаточно создать такую переменную через CREATE VARIABLE и не забыть в конце операций ее удалить.

Второй способ в отличие от первого позволяет выборочно отключать нужные триггеры, что гарантирует сохранение целостности данных.

Насчет глупых триггеров не согласен. Триггера замечательно могут защищать целостность и непротиворечивость данных от "глупых" разработчиков интерфейсных приложений, от работы с данными других систем и еще много от чего. Это единственный гарантированный способ контроля данных вне зависимости от доступа к БД. Все остальные способы или декларируют частичный контроль при соблюдении определенных правил или же накладывают существенные ограничения на работу с данными. Другое дело, что функциональность триггеров должна быть полной, чтобы самой не накладывать ограничения. В ASA триггера имеют достаточную функциональность для гибкой и мощной реализации, поэтому считаю, что грех ей не пользоваться.

Ну а зачем ХП что то писать в таблицу в обход триггеров - вариантов туча. От загрузки уже предварительно проверенных в ХП данных, до служебных надобностей. Ничего в этом удивительного не вижу, архитектор БД имеет полное право под свою ответственность отключать где нужно триггера.

konstantinesНе холивара ради: триггер, управляемый через глобальную переменную, ничего не гарантирует.
Мне бы хотелось услышать факты и доводы в подтверждение мысли, что он ничего не гарантирует. У меня в проектах замечательно гарантирует ;)

cherrex_DenНу вставлю и свои 5 копеек!
ASCRUS, ну чисто гипотетически представим, что запустились одновременно два триггера, один из запроса, второй из процедуры которая взвила некий флаг на который реагирует триггер. Учитывая что этот флаг глобальный, а не на уровне сессии или транзакции, то есть вероятность того, что оба триггера отработают одинокого. Хотя точно я не знаю, может и ошибаюсь.
Глобальные переменные в ASA сессионные. Поэтому если одна сессия создала глобальную переменную, только в ней она видна и будет и соответственно если на существование такой переменной повесить выход из триггера без выполнения действий (или же выполнения частичных действий), то для других сессий этот триггер будет работать как обычно. Сие кстати помнится описано в родной доке ASA в качестве примера борьбы с рекурсивным вызовом триггеров.

авторПросто запретите пользователям писать в эту таблицу вообще, но разрешите вызывать процедуру.
Ну вот пишем мы ХП, в которой помимо единичного изменения записи вставляем некую логику проверки этого изменения. Встает задача ... изменить группу записей, причем не все поля, а пару. Если при наличии триггера мы пишем UPDATE, в котором в SET перечисляем нужные поля и не паримся, то тут уже понеслась ... открыть курсор, организовать цикл, в цикле вызывать процедуру, получить и передать значения всех полей ... в общем вместо декларативного оператора организуем полноценный код, занимающий место, время и предполагающий ошибки.

konstantinesASCRUSпропущено...

Мне бы хотелось услышать факты и доводы в подтверждение мысли, что он ничего не гарантирует. У меня в проектах замечательно гарантирует ;)

Это до времени;)

Приконнектился пользователь (не админ) к базе isql-ем, создал переменную, и запорол целостность. Вручную, пользуясь исключительно своими легальными правами. И сессионность глобальных переменных в ASA - не помеха.
Чтобы создать переменную, пользователь должен знать о ней. Так что пример не засчитывается - триггера защищают от некорректной работы с данными, а не попыткой взлома и обхода логики сервера и БД. Тем более, эта проблема решается элементарной проверкой в триггере, что сессионная переменная создана из под пользователя с DBA правами. По моему такие проблемы решаются корректной логикой, а не ограничениями и запретами, в том числе на использование триггеров. В ASA в наличие все нужные функции и механизмы для того, чтобы писать корректную логику с минимальными усилиями и максимальной эффективностью.