Триггеры. - часть 2
select a.RDB$TRIGGER_NAME, a.RDB$RELATION_NAME, a.RDB$TRIGGER_SEQUENCE, b.RDB$TYPE_NAME, a.RDB$TRIGGER_SOURCE, a.RDB$TRIGGER_INACTIVE from RDB$TRIGGERS a, RDB$TYPES b where (a.RDB$TRIGGER_TYPE=b.RDB$TYPE) and (b.RDB$FIELD_NAME="RDB$TRIGGER_TYPE") and ((a.RDB$SYSTEM_FLAG = 0) or (a.RDB$SYSTEM_FLAG is NULL)) and (a.RDB$TRIGGER_NAME not in (select RDB$TRIGGER_NAME from RDB$CHECK_CONSTRAINTS));
Поле b.RDB$TYPE_NAME будет содержать расшифровку типа триггера, хотя она и отличается от той, к которой мы привыкли. На всякий случай приведу таблицу сооветствия значений типов, взятых из разных источников.
| Код | Значение из документации | Значение из таблицы RDB$TYPES |
| 1 | BEFORE INSERT | PRE_STORE |
| 2 | AFTER INSERT | POST_STORE |
| 3 | BEFORE UPDATE | PRE_MODIFY |
| 4 | AFTER UPDATE | POST_MODIFY |
| 5 | BEFORE DELETE | PRE_ERASE |
| 6 | AFTER DELETE | POST_ERASE |
Триггеры - это очень хорошо. Но бывают ситуации, когда нужно приостановить их работу. Например: нужно перенести данные из базы данных формата dbf, где ссылки между таблицами определяются значениями в некоторых полях. Самое простое - это перенести все значения как они есть, чтоб не нарушать ссылочную целостность, но, если в базе данных InterBase существуют триггеры, генерирующие уникальные значения, то возможет конфликт или нарушение ссылок. Сам попадался на этом. По этому было бы не плохо временно остановить работу триггеров. Попробуем получить скрипт для выполнения подобной операции.
SELECT "ALTER TRIGGER " RDB$TRIGGER_NAME "INACTIVE;" FROM RDB$TRIGGERS WHERE ((RDB$SYSTEM_FLAG = 0) OR (RDB$SYSTEM_FLAG IS NULL)) AND (RDB$TRIGGER_NAME NOT IN (SELECT RDB$TRIGGER_NAME FROM RDB$CHECK_CONSTRAINTS));
Если выполнить этот SQL-запрос в Windows ISQL, то из области результата можно скопировать готовый скрипт. Учтите, что в него попадут, не только триггеры, гинерирующие уникальные значения полей, но и другие, активность которых вполне можкт быть уместной. Поэтому рекомендую, получившийся скрипт скорректировать.