ARTURVУважаемые коллеги
Подскажите, нет ли системной функции для определения в триггере Update, какое поле обновлено.
Спасибо.
Артур
В триггере пишите:

ARTURVСпасибо за ответ.
Но мне хотелось бы не указывать конкретнное поле а получить имя поля, которое обновляется, а лучше список, если обновляется несколько полей. Хотелось бы вести свой лог изменений
Не стоит аудит вешать на триггера - называется прощай производительность и здравствуй тормоза. Быстрый способ обеспечить простейший аудит - на каждую таблицу сделать 2 колонки с DEFAULT значениями "Last User" и "TimeStamp" - в них ASA автоматически будет фиксировать логин пользователя и время во время добавления или изменения записи. Если же хотите заморочиться серьезнее, то значит нужно выносить механизм аудита на клиентскую часть или же делать сохранение данных клиентской части через ХП, в которых анализировать изменения и фиксировать их в логе.

iLLerТак что, если производительность падает, то это еще не повод переносить на клиента ведение аудита. Особенно, когда вся бизнес-логика реализована на серваке. А в некоторых случаях, как доступ по HTTP, это и невозможно в принципе.
Никто не мешает вынести запись данных в таблицы через ХП или в логический слой view + instead of триггера, в которых и будет писаться аудит. Это с одной стороны сохранит бизнес логику на сервере, с другой не будет тормозить массовые операции над таблицами (тем более что там аудит вряд ли будет нужен в виде фиксации каждой записи, измененной пользователем). Решений много, не спорю - но была поставлена общая задача - аудит с анализом изменения каждого поля записи, в этом случае я считаю вешать аудит на триггеры злом ;)

iLLerА анализ изменений - это вообще муха на луне. Процессору проще сделать миллион сравнений, чем тыщу чтений из памяти или одно чтение с диска. Так что на if, и прочие операции можно не обращать внимания. Профилировщик подтвердит мои слова, благо в 9-ке он есть.

А особенно если использовать нормальные серверные платформы, то данные зачастую оказываются не только в SQL кэше, но и в кэше процессорном. АСА хорошо оптимизирована в этом плане и время выполнения операций/запросов/процедур в миллисекундах доходит до фактического нуля.
Да что Вы говорите :) Давайте напишем AFTER FOR EACH ROW триггер на UPDATE таблицы с 20 полями, в котором анализируется, какие поля были изменены и по итогам анализа формируется и вставляется запись в таблицу аудита. А потом возьмем и сделаем пакетный UPDATE этой таблицы на миллион записей и сравним, как оно будет работать с триггером и как без триггера. Когда мы это сделаем, то сделаем закономерный следующий ход ... повесим на триггер условие WHEN VarExists(), чтобы была возможность отключать его во время пакетных изменений таблицы. Этот ход вынудит нас ввести дополнительное условие обновления таблицы - все процессы, делающие массовые обновления данной таблицы должны перед выполнением UPDATE создавать глобальную переменную для отключения триггера и удалять ее после проведения операции. Кода всем добавилось, централизованная логика размылась, ибо гарантировать, что где то не забыли создать и удалить такую переменную никто не может. Поэтому не вижу здесь смысла в такой овчинке, гораздо легче увести аудит на клиента или обязать клиентское приложение работать через бинес слой ХП или вьюверов.

Sergey OrlovВсе это так, да вот только в жизни я не видел клиента, который вызывает обновление всей таблицы, обычно это делает или разработчик или администратор, и то довольно редко и обычно, когда нет работающих клиентов, можно и подождать, а вот кто, когда и что изменил в записи, вот с этим приходится разбираться довольно часто...
Все зависит от задачи. В таких задачах как биллинги (коммуналка, телекоммуникация), системы статистического сбора и анализа информации массовые операции над большими объемами данных (импорт информации, расчеты, перерасчеты) вполне нормальное обычное явление и логировать их в аудит, да еще с изменением по полям - получается дорогостоящей операцией. Чтобы спор не выливался в религиозный, замечу, что я не против триггеров, но я за то, что детализация системы аудита должна быть обоснованной в рамках задачи ;)