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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 22.06.2016, 17:43   #9  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от ZornFire Посмотреть сообщение
delete from inventtable это вот зачем?
Именно

Цитата:
Сообщение от PTG Посмотреть сообщение
В R2, если не ошибаюсь механизм аналогичный AX5. Собственно мы перелезли с АХ5 на R3 и механизм уже другой.
и в r2 и в r3 существует понятие "иерархия таблиц"
в r2 эта иерархия настраивалась в справочнике аксапты.
в r3 эта иерархия существует в виде xml-файла, изменяется только в текстовом редакторе.

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

мало того, "удаление и обновление с сервера" приводит к тому, что на POS посылается команда "удалить" и тут же в пакете огромный набор данных для подчиненных таблиц. Ведь на POS подчиненные записи будут удалены и их придется обновлять с новой номенклатурой.

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

продукты, насколько я помню, находятся где-то в середине иерархии.
насколько я помню, к продуктам были пристроены с десяток других таблиц.

снятие галочки "Каскадное обновление" решает проблему с производительностью
но добавляет кучу геморроя с точки зрения целостности данных.

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

==========================
кстати, будете добавлять свои таблицы, также предельно внимательно следите за каскадным обновлением. с одной стороны каскадное обновление действительно гарантирует целостность. с другой стороны...

по идее, механизм обмена нужно делать более интеллектуальным. например, чтобы случаи "удаление-тутже-вставка" не приводили к каскадному удалению-вставке.

==========================
по идее число delete/insert должно быть минимальным всегда.
прежде чем менять настройки, галочки и джобы, разберитесь почему вообще возникают команды на удаление при реинициализации.

Последний раз редактировалось mazzy; 22.06.2016 в 17:48.
За это сообщение автора поблагодарили: PTG (1), AvrDen (1).
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
atinkerersnotebook: Setting Up A Retail Store With POS Blog bot DAX Blogs 1 09.12.2013 06:16
emeadaxsupport: AX 2012 R2 for Retail - Configuring POS for test mode with Dynamics Online payment service Blog bot DAX Blogs 0 11.10.2013 03:12
emeadaxsupport: AX for Retail: Managing and Maintaining POS Customizations Blog bot DAX Blogs 0 09.07.2013 06:18
Rahul Sharma: Dynamics AX for Retail POS Development Blog bot DAX Blogs 2 19.09.2011 15:30
Синхронизация данных двух БД (разные хосты) одним приложением Buba DAX: Программирование 2 02.02.2006 07:51

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

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

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