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

[oip]

А в чем состоит ваша задача? Вы вообще про что? Вместо "Ax insert/update/delete" нельзя использовать ничего другого, потому как в этих методах находится/может находиться часть бизнес-логики приложения.

[IKA]

Задача - логгировать определенные изменения данных в другую таблицу. Поэтому думаю, где лучше писать. На первый взгляд, для моей задачи преимуществ писать это на стороне sql не вижу, но, может, есть кие-то тонкости, о которых я не задумываюсь.
record.Insert/update так и останутся в аксапте, поэтому бизнес-логика не пострадает.

[oip]

Чем не устраивает стандартный журнал базы данных? Если не устраивает, то в любом случае что может быть проще, чем перекрыть insert/update в Аксапте? Тем более, сами же пишите, что "надо пересоздавать при каждой синхронизации таблицы". Есть что-то, что вас смущает, раз вы вопрос задали?

[mazzy]

Цитата:

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

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

Возможно, человек задумывается над тем, чтобы сделать железобетонный лог, который отлавливает даже doInsert/doUpdate и не отключается командой skipDatabaseLog.

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

[oip]

Цитата:

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

Возможно

Возможно. Но если это так, то я хочу это от человека услышать, прежде чем советы давать и домысливать за него. Пока этого не прозвучало.

"Вы забыли об этом спросить, но это дом для семейства слепых жирафов" (с) Джоэль
http://russian.joelonsoftware.com/Ar...erviewing.html

[IKA]

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

[mazzy]

Цитата:

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

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

1. а с чего вы взяли, что лог отслеживает только действия пользователей?
2. а почему именно в другую БД? Чем не устраивает вариант логирования в эту же БД, а затем перенос записей в другую БД средствами самой БД?

[petr]

Цитата:

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

Возможно, человек задумывается над тем, чтобы сделать железобетонный лог, который отлавливает даже doInsert/doUpdate и не отключается командой skipDatabaseLog.

Вообще то лог отлавливает doInsert/doUpdate. Специально в свое время проверял (была необходимость). Если сомневаетесь, то в salesLine строки вставляются именно командой doInsert() и лог (журнал БД) по ней работает.

[IKA]

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

[IKA]

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

[macklakov]

Цитата:

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

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

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

AX 4.0.2501.116

[AlexeyS]

Цитата:

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

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

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

[gl00mie]

Цитата:

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

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

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

[macklakov]

Цитата:

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

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

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

[Logger]

Цитата:

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

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

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

[macklakov]

Цитата:

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

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

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

[gl00mie]

Цитата:

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

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

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