в чем преимущества триггеров

[IKA]

спасибо, про doInsert, doUpdate напомнили ....получается, в аксапте, если я не использую аксаптовский лог я не смогу эти события отловить(

[IKA]

Получается, что триггеры лучше тем, что:
1) если не используется стандартный лог, то невозможно отловить вставки и удаления с помощью doinsert/doupdate
2) если используется update_recordset/insert_recordset, то переопеределение insert/update замедлит операции вставки/ обновления

[S.Kuskov]

Цитата:

Сообщение от IKA

Получается, что триггеры лучше тем, что:
...
2) если используется update_recordset/insert_recordset, то переопеределение insert/update замедлит операции вставки/ обновления

Если мне не изменяет память, skipDataMethods() работает и для update_recordset/insert_recordset

[ZVV]

Цитата:

Сообщение от S.Kuskov

Если мне не изменяет память, skipDataMethods() работает и для update_recordset/insert_recordset

Работает... Но тут вроде как их по смыслу никто скипать не собирается..

[IKA]

так точно, не собирается.

[macklakov]

Цитата:

Сообщение от oip

Чем не устраивает стандартный журнал базы данных?

Заметно тормозит систему.
Ситуация у нас такая, что идут постоянные бодания на тему:"кто накосячил". Несколько систем работает в связке, причем регулярно дорабатываются. Регулярно, посреди транзакции падает одна из систем или связка между ними. Пользователи с админскими правами тоже активно что-то правят. Регулярно обнаруживаются косяки и начинается поиск виноватых. Чтобы прикрыть задницу, ведется логгирование в файлах всего что входит/выходит через BC и основных таблиц в системном логе.
Т.к. в лог пишут все и сразу, он временами начинает задумываться над своей тяжелой жизнью. При этом гражданин должен ждать у конторки, пока чиновник выпишет ему документ лишние 10 секунд. Гражданин расстраивается. Чиновник расстраивается от того, что гражданин расстроился. Другой гражданин расстроился из-за того, что очередь образовалась. Все unhappy. Надо что-то делать.

AX 4.0.2501.116

[AlexeyS]

Цитата:

Сообщение от macklakov

Заметно тормозит систему.
Ситуация у нас такая, что идут постоянные бодания на тему:"кто накосячил". Несколько систем работает в связке, причем регулярно дорабатываются. Регулярно, посреди транзакции падает одна из систем или связка между ними.

На уровне БД конкретного пользователя не отловить, все подключаются под учеткой AOS-а. А вот если какая-то программа лезет напрямую в базу, то это возможно отловить только триггерами.

[Logger]

Цитата:

Сообщение от macklakov

...Пользователи с админскими правами тоже активно что-то правят. Регулярно обнаруживаются косяки и начинается поиск виноватых. Чтобы прикрыть задницу, ведется логгирование в файлах всего что входит/выходит через BC и основных таблиц в системном логе.
AX 4.0.2501.116

Если речь идет о косяках пользователей, то может быть подрезать им права ?
А сами они непосредственно ведь не пишут в транзакционные таблички. Так что их можно и не логировать.
Кстати, при желании, можно отлавливать все нажатия на кнопки в системе. sysSetupformRun в этом поможет. Тормозов особых не добавит.

[gl00mie]

Цитата:

Сообщение от AlexeyS

На уровне БД конкретного пользователя не отловить, все подключаются под учеткой AOS-а.

В 4.0 не отловить, а вот в 2012 можно включить запись информации о пользователе в контекст SQL-соединения, см. Troubleshooting database performance. Собственно, в AX 2012 без этого не посмотреть, как прежде, какие SPID'ы какой пользовательской сессией используются.

[macklakov]

Цитата:

Сообщение от Logger

Если речь идет о косяках пользователей, то может быть подрезать им права ?

Не вариант. Иногда это косяк пользователя, иногда косяк в аксе, иногда в интеграции. Задача постфактум выяснить, в чем лажа.
Клиент нервный, но очень важный. Поэтому чтобы в чем-то убедить, доказательства должны быть очень надежными.

[macklakov]

Цитата:

Сообщение от AlexeyS

На уровне БД конкретного пользователя не отловить, все подключаются под учеткой AOS-а. А вот если какая-то программа лезет напрямую в базу, то это возможно отловить только триггерами.

createdby, modifiedby должно хватить

[gl00mie]

Цитата:

Сообщение от macklakov

Чтобы прикрыть задницу, ведется логгирование в файлах всего что входит/выходит через BC и основных таблиц в системном логе. Т.к. в лог пишут все и сразу, он временами начинает задумываться над своей тяжелой жизнью.

По-моему, это - почти чисто админская (в смысле DBA) проблема, а не аксаптовая. Да, есть одна таблица, в которую куча народу накидывает кучу записей, да, она может разрастаться до десятков процентов от размера всей базы, да, иногда вставка записи в нее может задумываться на несколько секунд, тормозя обработку данных, удлинняя транзакции, приводя к дополнительным блокировкам и т.п. Ну и что, из-за этого сама идея перестает быть хорошей? Один из вариантов решения - партицирование таблицы по какому-то левому полю, значение которого хорошо распределено между сессиями. Можно добавить поле по аналогии с LedgerBalancesDimTrans.LedgerBalancesVariant, которое заполнять каким-нить остатком от деления кода сессии на константу, и вот по этому полю партицировать таблицу. А еще регулярно избирательно чистить ее, чтобы она не разрасталась до непомерных размеров, - для этого может потребоваться дополнительное партицирование по LogTableId.

[Logger]

А еще лучше хранить в SysDatabaseLog стек вызовов и прочие полезные плюшки.
позволяет понять - пользователь накосячил или функционал кривой.