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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 30.04.2010, 07:09   #1  
Alexx7 is offline
Alexx7
Сам.AX
Аватар для Alexx7
Самостоятельные клиенты AX
1C
 
305 / 28 (1) +++
Регистрация: 22.07.2009
Падают помощники при закрытии запасов AX40sp2
Добрый день уважаемые пользователи форума axforum.info.

Пробую на копии рабочей БД закрывать запасы. При этом выставляю параметры при закрытии: спрецификация - "Код номенклатуры"; обновить производства - истина; обновить главную книгу - истина; выполнить пересчет после закрытия - ложь. Для ускорения процесса начинаю запускать помошников расчета с разных машин. Через некоторе время помошники начинают один за другим отваливаться с сообщением об ошибке:
Цитата:
Невозможно отредактировать запись в Журнал (ProdTableJour).
Возник конфликт обновления из-за того, что другой пользовательский процесс выполняет удаление записи или изменение одного или нескольких полей в записи.
Вот. Незнаю на что грешить. Закрываю на копии(!) БД, т.е. кроме закрытия и помошников в базе никого нет.

Пробовали делать на чистом приложении (без слоев var, vap, usr, usp), но с нашей БД - ошибка не исчезла. Помошники так же отваливаются как и на нашем приложении.

Посоветуйте.

Спасибо.
__________________
Возьми свет!
Старый 30.04.2010, 11:38   #2  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,894 / 5650 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Это явно некоторая недоделка стандартного закрытия в 4ке. Более того - поскольку эту ошибку не смогли исправить, в версии 2009 весь функционал обновления производства из закрытия - выключен.
Проблема в том, что почти во всех случаях, 4ка по умолчанию использует оптимистический режим блокировок. Типа - не будем блокировать записи, авось они не поменяются. Если другой процесс чего-то поменял - просто тупо повторим наши операции. Поскольку в закрытии, хелперы распределены по-номенклатурно, вероятность конфликта между ними мала. Однако же, в случае обновления шапки производственного заказа (и вообще информации по ПЗ), это естественное разделение обязанностей между хелперами перестает срабатывать и они часто начинают наступать друг другу на хвост, рестартовать транзакции и пересчитывать очередную порцию номенклатур. Поскольку конфликтуют они часто, то есть большие шансы что случится 5 и более рестартов транзакции подряд и система сгенерирует ошибку, про которую ты написал.

Возможных вариантов решения проблемы два и оба они кривые:
1. Пройтись по классам inventCostItemDim, inventCostClosing,InventCostHelp и в выражении (xSession::currentRetryCount() >= #RetryNum) поменять #retryNum на какое-нить число побольше (типа 20 или 30). Минус варианта в том, что у тебя все равно будут происходить конфликты и большая часть хелперов будет работать в пустую, постоянно начиная и откатывая транзакции, напрягая БД но не делая при этом ничего полезного.
2. Пройтись по классу inventAdj::updateModuleProdLine и подправить его таким образом, чтобы все обновляемые записи из производственных таблиц селектились в режиме pessimisticLock. (Конечно придется сделать пессимистические клоны всех этих find(), inventtrans.prodBOM()) и тп. Вариант не сильно лучше предыдущего, ибо большая часть хелперов быстренько начнут друг друга блокировать и скорее всего будут тупо отваливаться по дидлокам.

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

X++:
while select inventSettlement
where inventSettlement.voucher==inventClosing.voucher && inventSettlement.transDate==inventClosing.transDate  &&
inventSettlement.TransRecId  != 0                        &&
inventSettlement.SettleModel != inventSettleModel::PhysicalValue
join inventTrans
where inventTrans.recId==inventSettlement.transRecId
{
      ttsbegin;
      inventAdj::updateModule(inventrans,inventSettlement.adjustment,inventClosing);
      ttscommit;
}
После всего этого, надо будет проверить как отмена закрытия отрабатывает. Если она не восстанавливает значения в производственных таблицах, то надо для этого случая сделать такой же примерно код, но вместо inventClosing.voucher подставить inventClosing.cancelVoucher.
В трешке была давняя ошибка, из за которой при отмене закрытия система курочила данные в производственных проводках даже если в закрытии соответствующая галка не стояла. Так что в трешке в закрытии (при использовании производства конечно)всегда надо было ставить соответствующую галочку, если не хотелось поиметь проблем при отмене закрытия. Если в 4ке эту ошибку не исправили (нет под рукой чтобы посмотреть), то скорее всего - никакой специальной обработки для отмены закрытия делать не понадобится, система сама все сделает благодаря ошибке .
За это сообщение автора поблагодарили: lev (5), oip (2), S.Kuskov (4), Alexx7 (1).
Теги
закрытие склада

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Разграничение доступа на разные журналы запасов maximka DAX: Функционал 2 08.10.2009 16:15
Оборачиваемость запасов Андре DAX: Функционал 47 28.09.2006 16:22
Ранжирование запасов по числу обращений Андре DAX: База знаний и проекты 7 11.01.2006 12:42
Что то не понятное при закрытии склада visual DAX: Функционал 4 04.07.2005 09:54
Финансовые проблемы при Закрытии склада Владимир Ю. DAX: Функционал 6 28.06.2005 20:00

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

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

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 21:37.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.