VovakaНеобходимо реализовать сабж. Как бы это сделать в ASA поизящней ? Навешивать триггеры на сотню-другую таблиц не очень прельщает ... может есть какой другой вариант ?

Зачем навешивать триггера? Оставим это для фанатов IB/FB, которые считают,
что лог транзакций - это зло и гордятся его отсутствием в своем любимом сервере.
;)))
Так вот, если нужно протоколировать любые изменения данных, типа update, insert
delete, то лог транзакций и есть этот самый протокол.
Смотри dbtran.exe или в утилитах translate log file
Естественно, что сервер должен быть запушен без ключа -m и при бэкапе если лог
отрезается, то должен переименовываться.

Vovaka
Где-то читал, что в Informix есть встроенный механизм аудита, нет ли ничего подобного в ASA ?

Если информации по всем insert/delete/update недостаточно, то можно включить
более детальный аудит. Опция базы AUDITING=ON
Но это заметно увеличит лог транзакций.
См. в хелпах про auditing

Рыжий КотASCRUS,
мне как-то нужно было определить точный
ip-адрес машины, откуда было совершено действие,
но транслация лога при включенном аудите ничего не дала.
Это дело уже пофиксили или нет?


Не знаю, пофиксили ли это, но это можно обойти, сделав event на коннект пользователя, там определить ConnectionID а по нему уже получить
connection_property('NodeAddress',ConnectionID).
И записать куда-нибудь это

Рыжий Кот
Решение интересное, только вот на момент возникновения данной ситуации event создан не был. Как я понимаю, аудит создается с целью записи дополнительной информации о действиях, происходящих в базе и это очень странно, что записывается вход пользователя, но не фиксируется адрес, откуда он произвел подключение.


А это уже вопрос корпоративной политики. У нас пользователи отвечают за действия, произведенные под их логинами. Если юзер кому-то сообщил свой пароль, то сам виноват. В таком раскаладе абсолютно неважно, с какого компа что делалось.

Хотя может я не угадал цель.

Vovaka
Хотелось бы иметь возможность это все смотреть из клиентского приложения, продукт продаваемый и зачастую те, кто им пользуются не в состоянии объять "необъятное". Как правило говорят - должна быть кнопка, которую нажал и увидел кто, что и когда поменял :)

А будет ли интересна пользователю информация в виде многих тысяч записей
вида "Vasya в 13:30 12/11/04 сменил в таблице table в записи с ID=1234 значение
поля field на 4321"?

Протоколирование действий с объектами более высокого уровня, чем записи в
БД - это уже более прикладная задача.
Возьмем для примера накладную. В простейшем варианте это 2 таблицы: шапка и строчки. Накладная допустим имеет два статуса: черновик и проведена.
Логичнее предоставить пользователю такой протокол:
Создана
Изменена (без детализации изменений)
Проведена
Возвращена
Изменена
Проведена

А совсем уж детальный разбор полетов IMHO вряд ли назовешь штатной потребностью.

--
http://talk.ru/forum/talk.ru.accounting.development