AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 20.09.2005, 09:19   #1  
chi is offline
chi
Участник
 
80 / 13 (1) ++
Регистрация: 21.01.2004
Механизм отката операций
На днях возникла следующая мысля на тему отката операций. Охота получить порцию критики о целесообразности таковой.
Идея следующая:

Принцип действия механизма основан на возможности журнализации базы данных средствами Axapta. В связи с этим для использования механизма необходимо, чтобы была активирована лицензия «Database Log», и включен конфигурационный ключ «Журнал базы данных». Помимо возможности журнализации базы данных здесь также используется механизм трассировки SQL-запросов. Перед началом операции, для которой впоследствии может потребоваться возможность отката, включается трассировка SQL-запросов и журнализация тех таблиц, в которые вносятся изменения в процессе выполнения операции. Список таблиц для каждой операции берется из таблицы 1 (изначально она пуста). По окончании операции отключаются механизм трассировки SQL-запросов и журнализация базы данных. Необходимым условием является, чтобы операция не содержала вывод каких-либо диалоговых окон (исключая infolog об окончании операции и Progress Operation).
Далее анализируется набор выполненных SQL-запросов. Если в процессе операции были выявлены изменяемые таблицы, которые не присутствуют в таблице 1, то они вносятся в эту таблицу. В этом случае откат по этому конкретному экземпляру операции будет невозможен. Однако в таблицу 1 будут внесены все необходимые таблицы, чтобы обеспечить откат при последующих выполнениях этой операции. Если в процессе анализа SQL-запросов новых таблиц не выявлено, то из таблицы SysDatabaseLog в таблицу 2 копируются записи SQL-операций, влияющих на изменения в таблицах базы данных. В эту же таблицу копируются модифицированные записи всех таблиц (***).
Далее при необходимости отката выполненной операции из таблицы 2 в обратном порядке изымаются записи, и выполняются действия обратные тем, что указаны в таблице 2. (т.е. если была операция insert, то выполняется delete [это не всегда - исключения ниже]). Перед выполнением отката записи всех таблиц, участвующих в операции, проверяются на эквивалентность тем, что сохранены на шаге *** (см. выше) , указанных в таблице 2 на момент совершения операции. Если соответствия нарушены, то откат будет невозможен. Этим достигается невозможность отката, если после операции была выполнена другая операция, которая повлекла за собой изменения в тех же записях, что и первая операция.
Исключением здесь являются таблицы LedgerBalancesTrans и LedgerBalancesDimTrans.

Надеюсь объяснил понятно.
Ваше мнение.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Произвольное объединение компаний для отчетов и операций в них gl00mie DAX: Программирование 11 07.08.2006 14:22
механизм динамич.-статич.сводных планов sev DAX: Функционал 7 27.02.2006 09:18
Планирование производственных операций Vikp DAX: Функционал 4 10.01.2006 15:43
Механизм нескольких касс алексей DAX: Функционал 0 23.11.2005 11:04
Исследование отката платежного поручения Anton Sk. DAX: Функционал 1 24.12.2001 13:58

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 01:53.