Привет всем.

Никто не знает можно ли как-нибудь обойти ошибки в триггере? Поясню.
Например есть триггер:

create trigger update_test on test for insert
as
insert test_upd (a,b) select a,b from inserted

Соответственно, если например, в таблице test или test_upd удалить столбец b, то insert на который сработал триггер не выполнится. Можно ли как нибудь обойти эту ошибку, чтобы ошибка в триггере не вызывала ошибку запроса на который триггер сработал?
Можно конечно проверять структуры таблиц test & test_upd но это не очень быстрый вариант или это можно сделать быстро?

С уважением, Alexander

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

Regards, Alexander.

2Genady:
Ну задача у меня такая Ведь кроме реализации бизнес правил и/или ссылочной целостности на триггерах можно делать еще много чего другого. Аудит например. Конечно на момент написания триггера я знаю структуру базы, но она может измениться со временем, а меня рядом не будет и нужно чтобы все не упало.

--
Народ!! Извините, но же не спрашиваю "а нужно ли мне триггер вешать?" Просто интересно может, кто знает - как можено игнорировать или обработать ошибку в триггере? На сколько я понял это не возможно, просто может все-таки есть какие-нибудь хитроумные методы

С уважением, Александр.

Ну вот, совсем запинали

2GreenSunrise: Наверное, я правда написал "Лажу" в самой постановке вопроса. Согласен, что понятие "структура базы" включает в себя и триггера.

Давайте я все-таки еще одну попытку сделаю.

Есть универсальная система аудита.
Триггера формируются автоматически этой системой. Соответственно она предназначена для различных компаний, которые хотят добавить возможность аудита к используемому софту, если в нем эта возможность отсутствует.
Расказ в трех действующих лицах . Соответственно имеем три лица. (буду называть всех сокращенно:
ПП - производитель программы
ПО - пользователь программы (и системы аудита)
ПА - производитель системы аудита)

Сам пример:
ПП производит систему бух.учета. ПО пользуется этой системой, но в ней отсутствует аудита изменений в БД. Тогда ПО обращается к ПА и берет у него систему аудита. Система аудита создает триггера на необходимые таблицы и выдает отчеты на основании данных аудита. В один прекрасный день ПП - присылает update к базе данных. ПП вовсе и неподозревает о существовании ПА с его системой аудита. После запуска update - необходимо перезапустить систему аудита, чтобы она проверила, какие таблицы были изменены и пересоздала необходимые триггеры. Однако если ПО забудет это сделать, то скорее всего при выполнении триггеров будут происходить ошибки, что повлечет развал всей БД . По этому мне (как ПА) необходимо это предусмотреть, для чего можно: либо встроить проверку на изменение структуры БД в триггера, либо игнорировать ошибки с alert'ом в систему аудита.

Извините за столь запутанные объяснения. Может быть это не очень наглядный пример.

С уважением, Александр.

У меня точно такие же мысли. Главное написать, что если реинсталл не запустите - то я не виноват

2alexeyvg:

Может (должен) запустить - но если не запустит проверка нужна для подстраховки, чтобы база не разъехалась. (Я думаю что это просто будет опционально. Если Очень важно чтобы все работало - то вставляется доп. проверка на структуру таблиц.

2garya:

Как раз из-за того, что inserted & deleted изменяются вместе со структурой таблицы, я и хочу делать проверки чтобы небыло ошибок. Ваш вариант очень интересный, но в моем случае к сожалению не подойдет (из за изменения структуры inserted&deleted).

PS. Когда все будет готово я дам ссылку на тестовую версию - может быть кому-нибудь будет интересно поиграться.