Определить изменилась ли запись в триггере?

← →
Ярослав (2005-09-01 07:07) [0]

У меня есть триггер на изменение записи (before update) в нем мне нужно произвести действия если запись была действительно изменена, а если нет то делать ничего не надо.
Как мне определить что запись действительно изменена?
Можно сравнивать все поля на предмет old.field=new.field, но мне нужно производить это действие для нескольких таблиц, а у них набор полей соответственно различен, есть ли способ сделать это как то универсально, т.е. один и тот же код для триггеров различных таблиц?

← →
ANB © (2005-09-01 09:04) [1]

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

← →
Sergey_Masloff (2005-09-01 09:06) [2]

ИМХО нельзя. Код триггера 1) не интерпретируемый 2) Не знает для какой таблицы он вызывается.
Вообще подобные вещи делаются инструментально CASE средствами (генерится статический код) а не наживается геморрой с динамическим кодом триггера

← →
Sergey13 © (2005-09-01 09:17) [3]

Если тригер before update сработал, то почему остались сомнения в том, что запись изменена?

← →
Zacho © (2005-09-01 09:24) [4]

Sergey13 © (01.09.05 9:17) [3]

Потому что запись может быть и не изменена :) Напимер, UPDATE MY_TABLE SET MY_FIELD=MY_FIELD

← →
Sergey_Masloff (2005-09-01 09:24) [5]

Sergey13 © (01.09.05 09:17) [3]
>Если тригер before update сработал, то почему остались сомнения >в том, что запись изменена?
update sometable set somefield = somefield where id = key

← →
Sergey_Masloff (2005-09-01 09:25) [6]

Zacho © (01.09.05 09:24) [4]
;-)

← →
Виталий Панасенко (2005-09-01 10:04) [7]

> Zacho © (01.09.05 09:24) [4]
> Sergey13 © (01.09.05 9:17) [3]
>
> Потому что запись может быть и не изменена :) Напимер, UPDATE
> MY_TABLE SET MY_FIELD=MY_FIELD

Если все грамотно сделано, то БД останется в том же состоянии
что и до UPDATE (только что-то типа логов может поменятся).. Я так думаю.. А там - ... его знает !..:-))

← →
Sergey13 © (2005-09-01 10:25) [8]

2[4] Zacho © (01.09.05 09:24)
[5] Sergey_Masloff (01.09.05 09:24)

Синхронно однако. 8-)

Это оч-ч-ч-чень частный случай. И к тому же ИМХО весьма редкий. Я не думаю, что это постоянная практика. Данные остались такими же с логической точки зрения. Физически они изменились.

← →
Sergey_Masloff (2005-09-01 11:27) [9]

Sergey13 © (01.09.05 10:25) [8]
>Я не думаю, что это постоянная практика
Извини, ошибаешься. Очень многие инструментальные стредства генерят именно такой код. Всякие Oracle Forms (а на них пишется поболее чем на дельфях, ИМХО). Понимаю что вопрос по интербейсу но с ним ситуация похожая - тулзы часто такой код генерят.
А человек хочет ловить важные с т.з. бизнес-логики изменения. Если моя зарплата изменилась с N на N это не изменение а если с N на 10*N то имхо для истории нелишне зафиксировать автора изменения.

← →
Sergey13 © (2005-09-01 11:40) [10]

2 [9] Sergey_Masloff (01.09.05 11:27)
>Очень многие инструментальные стредства генерят именно такой код.
Может быть. Спорить не буду. Хоть и не думаю, что описанное тобой имеет свойство быть у автора. Хотя - кто знает.

Тогда можно посоветовать автору, попробовать ловить одинаковость на другом конце - там где он что-то делает или не делает по событию. Может там можно придумать универсальное решение. Хотя сомневаюсь я в этом. Универсальность тут может достигаться только использованием чтения метаданных и динамического СКЛ на их основе (другого пути я не вижу). А это не есть гуд в тригерах. ИМХО. Проще все old.field=new.field перебрать.

← →
Sergey_Masloff (2005-09-01 12:23) [11]

Sergey13 © (01.09.05 11:40) [10]
>Универсальность тут может достигаться только использованием >чтения метаданных и динамического СКЛ на их основе (другого >пути я не вижу). А это не есть гуд в тригерах. ИМХО. Проще все >old.field=new.field перебрать
Это 100%. Тем более написать в ERWIN скрипт который сгенерирует этот перебор в триггере - задача элементарная.

← →
Игорь Шевченко © (2005-09-01 18:41) [12]

> А человек хочет ловить важные с т.з. бизнес-логики изменения.
> Если моя зарплата изменилась с N на N это не изменение а
> если с N на 10*N то имхо для истории нелишне зафиксировать
> автора изменения.

А для истории не хреново бы фиксировать все изменения такого рода, вне зависимости от значения. Это так, к слову.

← →
Ярослав (2005-09-02 06:38) [13]

>> Игорь Шевченко © (01.09.05 18:41) [12]
>> А для истории не хреново бы фиксировать все изменения такого рода, вне зависимости от значения. Это так, к слову.

???
Даже тех которых не было???
Пользователь открывает форму, ничего не делает на ней и жмет "Сохранить" Естественно запись примет теже самые значения т.е. не будет изменена, а триггер сработает и запишет в историю тоже самое? Я хочу чтобы такого небыло. На клиенте отслежывать изменил чтото пользователь или нет, я считаю несколько не правильно.

← →
Sergey13 © (2005-09-02 09:18) [14]

2 [13] Ярослав (02.09.05 06:38)
А нафига сохранять что либо, если ничего не сделано?

>Я хочу чтобы такого небыло.
Никто тебя и не побуждает делать так. 8-)

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

← →
Виталий Панасенко (2005-09-02 10:11) [15]

> Пользователь открывает форму, ничего не делает на ней и
> жмет "Сохранить"

Если используешь DBControls, то по нажатию "Сохранить" ничего и не будет сохранено (если, конечно, в обработчике ничего загадочного не делать, кроме Post) т.к. НД будет в сосотоянии dsBrowse

← →
ККВ (2005-09-02 10:43) [16]

Попробывать применить условие:
if old.value<>new value then
что-то делать

> На клиенте отслежывать изменил чтото пользователь или нет,
> я считаю несколько не правильно

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

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

А почему либо-либо? Лучше делать и. А вдруг потом придумаешь сделать еще и морду на php?

А разве нельзя воспользоваться событиями TDataset?

> ???
> Даже тех которых не было???
> Пользователь открывает форму, ничего не делает на ней и
> жмет "Сохранить" Естественно запись примет теже самые значения
> т.е. не будет изменена, а триггер сработает и запишет в
> историю тоже самое? Я хочу чтобы такого небыло. На клиенте
> отслежывать изменил чтото пользователь или нет, я считаю
> несколько не правильно.

А нафига по сети гонять то, что не менялось ?

Определить изменилась ли запись в триггере? Найти похожие ветки