-
ALTER TRIGGER [trgSettings] ON [dbo].[tSettings]
AFTER INSERT, DELETE, UPDATE
AS
BEGIN
BEGIN TRANSACTION
DECLARE
@IdSetting int,
@Section nvarchar(32),
@Ident nvarchar(32),
@Value nvarchar(32),
@iDate datetime,
@iUser int,
@uDate datetime,
@uUser int,
@Note nvarchar(255),
@Now datetime,
@i int;
SET @Now = GETDATE();
SET NOCOUNT ON;
IF EXISTS(SELECT * FROM Inserted)
BEGIN
IF NOT EXISTS(SELECT * FROM Deleted)
BEGIN
ROLLBACK TRANSACTION
END
ELSE
BEGIN
COMMIT TRANSACTION
END;
END
ELSE
BEGIN
COMMIT TRANSACTION
END;
END В какой части текста триггера лучше всего открывать глобальную, по отношению к триггеру, транзакцию ?
-
Транзакции в триггере есть безусловное зло :)
-
Как же все-таки гадость, этот ваш... триггер !
-
Ребят кому не сложно, можно ваши триггеры посмотреть, большей частью интересуют «сложно выпоенные» триггеры. Не беда если я в них не разберусь, просто хотелось посмотреть как их (триггеры) делают если можно так сказать профессионалы.
Спасибо.
-
профессионалы стараются избегать триггеров
-
> Polevi © (29.08.08 12:02) [4]
А как же тогда логирование изменений, обеспечение целостности информации и т.д. ? Да, и насколько в среднем триггер замедляет процесс обработки данных ?
-
> А как же тогда логирование изменений, обеспечение целостности > информации и т.д.
целостность информации обычно обеспечивается декларативными средствами. Про транзакции и триггеры рекомендую почитать: http://sql.ru/forum/actualthread.aspx?tid=588877 все страницы
-
Для чего эта проверка?
> > IF EXISTS(SELECT * FROM Inserted) > BEGIN > IF NOT EXISTS(SELECT * FROM Deleted)
-
> профессионалы стараются избегать триггеров >
+1.
> А как же тогда логирование изменений, обеспечение целостности > информации и т.д. ?
целостность данных обеспечивается средствами самой СУБД, такими как PK-FK constraints, нафига для этой цели триггеры - непонятно.
Логгирование отлично обеспечивается из других мест (ХП, например).
За 8+ лет работы с БД триггер понадобился один единственный раз.
-
> Для чего эта проверка?
А как, по-твоему, устроена операция Update? Сначала Delete, потом Insert
-
Ega23 © (29.08.08 12:11) [9] т.е. для определения операции?
-
> stas © (29.08.08 12:09) [7]
В зависимости от события INSERT, UPDATE, DELETE, делать "разные вещи"...
-
не проще 3 триггера сделать?
-
> т.е. для определения операции?
Ну судя по тексту - да.
-
> stas © (29.08.08 12:17) [12]
Мне кажется нет...
-
Ну, или
IF <Условие> --определяем UPDATE BEGIN Declare ... END
IF <Условие> --INSERT BEGIN Declare ... END
IF <Условие> -- DELETE BEGIN Declare ... END ... Insert into
без всяких транзакций
-
> Ega23 © (29.08.08 12:21) [13]
Не по тексту судить не надо, этот текст к примеру...
-
> stas © (29.08.08 12:23) [15]
А допустим если необходимо при разных событиях иметь общию(ии) переменные...
-
Вверху общие.
Я сразу скажу этот лог (как в примере) работать будет некорректно при пакетной вставке, удалении обновлении.
У нас огранизован лог подобный лог (я не настаиваю на его правильности) 3 триггера на таблицу. Внутри просто Insert into... select f1..fn from inserted. Каждую ночь таблицы LOG списываются в архив и очищаются, т.к. при наполнении таблицы лога вставка происходит все медленее.
-
> А как, по-твоему, устроена операция Update? Сначала Delete, > потом Insert
а почему не наоборот ?
|