|
ASE, update trigger, отловить изменения в PK
|
|||
---|---|---|---|
#18+
Есть таблицы: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
Хочется сделать лог изменений a в b. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Это идеально работает для простых полей. Но делает чушь если обновление произошло в поле id. Спрашивается, как быть? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2015, 18:24 |
|
ASE, update trigger, отловить изменения в PK
|
|||
---|---|---|---|
#18+
White Owl, придумать как сравнивать записи без условия Код: sql 1.
условие 100% не выполняется при обновлении Id... ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2015, 19:10 |
|
ASE, update trigger, отловить изменения в PK
|
|||
---|---|---|---|
#18+
Если другого уникального идентификатора записи нет то сопоставить deleted <-> inserted - ИМХо задача не тривиальная :). Добавляйте identity поле в таблицу a и ориентируйтесь на него... ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2015, 19:12 |
|
ASE, update trigger, отловить изменения в PK
|
|||
---|---|---|---|
#18+
White Owl, первичный ключь менять нельзя. я думал, ты знаешь... ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2015, 19:53 |
|
ASE, update trigger, отловить изменения в PK
|
|||
---|---|---|---|
#18+
MasterZivWhite Owl, первичный ключь менять нельзя. я думал, ты знаешь... Я знаю. Это мы озаботились наконец приделать отчетность к одному древнему проекту. Таблицы там менять нельзя иначе клиент умрет, а он еще на PB6.5 написан.... И в этом клиенте запросто можно менять первичный ключ. Да и используются эти таблицы в оооочень многих хранимых процедурах (около трех тысяч уже)... В общем, сижу грущу. А вдруг у inserted-deleted есть какой-нибудь тайный rowid? Или как-нибудь через if update () and @@rowcount=1 можно извернуться? Как бы к ASE 15 приделать триггер на for each row? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2015, 21:37 |
|
ASE, update trigger, отловить изменения в PK
|
|||
---|---|---|---|
#18+
White Owl, так же все просто. Если изменился первичный ключ триггер нужно откатывать ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2015, 22:05 |
|
ASE, update trigger, отловить изменения в PK
|
|||
---|---|---|---|
#18+
MasterZivWhite Owl, так же все просто. Если изменился первичный ключ триггер нужно откатыватьЭто пойдет вразрез с нынешними business rules. Я не могу просто запретить изменять PK, он естественный и значит может меняться. К сожалению, клиент в этом случае тупо делает update. Если бы он разбивал операцию на delete-insert то и проблем бы не было... ..... а впрочем. Если верить документации, то при update эти самые deleted и inserted таблицы заполняются не одновременно. Сначала старые строки переносятся из таблицы в deleted, потом новые строки одновременно копируются в таблицу и inserted. Если можно сыграть на этом, то... ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2015, 22:31 |
|
ASE, update trigger, отловить изменения в PK
|
|||
---|---|---|---|
#18+
А собственно говоря. Если PK меняется, то мы всегда можем это рассматривать как пару удалить-вставить. А значит и триггер на обновление превращается в: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
В общем-то, вполне нормально получается. То что в реальности PK был обновлен через update, нам в логе знать вовсе не обязательно. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2015, 22:50 |
|
ASE, update trigger, отловить изменения в PK
|
|||
---|---|---|---|
#18+
White OwlMasterZivWhite Owl, так же все просто. Если изменился первичный ключ триггер нужно откатыватьЭто пойдет вразрез с нынешними business rules. Я не могу просто запретить изменять PK, он естественный и значит может меняться. К сожалению, клиент в этом случае тупо делает update. Если бы он разбивал операцию на delete-insert то и проблем бы не было... ..... а впрочем. Если верить документации, то при update эти самые deleted и inserted таблицы заполняются не одновременно. Сначала старые строки переносятся из таблицы в deleted, потом новые строки одновременно копируются в таблицу и inserted. Если можно сыграть на этом, то... На самом деле не важно, как у тебя будет выполнена эта операция физически. Логически невозможно соотнести друг с другом строки из набора старых и новых версий строк, невозможно сформировать пары (старая строка--новая строка), потому что первичный ключ меняется. И отсюда кстати --- очевидный выход. Надо добавить ещё один ключ (уникальный), который никогда не будет меняться . Делается это вполне себе легко, добавляется поле, в него кладётся например значение старого ключа, или номер по порядку, по вкусу, в триггере запрещается его модификация, в дефолте генерируется уникальное значение (или можно использовать identity) -- и тогда ты сможешь в триггере на UPDATE всегда сотнести друг с другом старую и новую версию записи по значениям этого нового ключа, которые никогда не меняются. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.04.2015, 01:48 |
|
|
start [/forum/topic.php?fid=55&msg=38933520&tid=2009770]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
58ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
2ms |
others: | 16ms |
total: | 184ms |
0 / 0 |