Отслеживание изменений данных в ERP. История возвращения журнала базы данных

[vmoskalenko]

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

Цитата:

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

1) CT (Change Tracking) - тут не подходит по смыслу, потому что не логирует версии данных, а только факт того, что они менялись, т.е. список ключей, например, recid.

Тут у нас есть опыт. Делали именно на CT триггер для отправки данных в 3rd-party application из Data Entity.

Очень много багов. Так как делать надо было быстро, то все делали сами, т.е. практически переписывали стандартный X++ код работы с CT.
Например, в версии 10.0.4 Майкрософт совсем сломал CT, но быстро выпустил обновление для 10.0.4.

Вобщем, то что сделали получилось лучше и стабильней. Но исправлять ошибки в самом SQL уже не стали и пришлось придумывать "Монитор".

Так вот, Монитор.
Потом мы его немного допилили по своему усмотрению. И добавили запись в таблицу логов. За основу интерфейса взяли стандартный Database Log. За улучшением UI/UX не гнались, т.к. это внутренняя тулза, для разборов полётов. Но с ссылочными полями получилось хорошо. Потому что мы сохраняем Data Entity запись на каждое изменение в ней.

Ой, не правду говорю... Не на каждое изменение, а на каждое сканирование CT по изменениям. Так как клиент хотел быстрее, то сканирование проходило с частотой 1 раз в минуту. И для целей логирования это хорошая частота дискретизации. (60Гц? ;-) )

Итого, для CT есть две проблемы

• не всегда стабильно. Нужны костыли
• имеет дискретность (минимум 1 раз в минуту)

Но имеет приемущество, так как суть Data Entity - плоская репрезентация данных, то данные для конечного пользователя выглядят красиво и понятно.