Показать сообщение отдельно
Старый 06.09.2006, 13:14   #7  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от ToRo
Мы тоже столкнулись с подобной проблемой при проверке и корректировки запасов в наличии. Конкретно в этом механизме обнаружилась интересная бага, которая долго работает вроде над построением прогресс-бара.
При большом количестве номенклатуры время проверки-корректировки близилось к бесконечности.
Недавно читал блоги и наткнулся на описание подобной проблемы, правда, симптомы там были немного другие: тоже длительное время отрабатывала проверка целостности на запасах, в результате чего винда ругалась на отсутствие winsta.dll По ссылкам обнаружил описание и решение проблемы. Оно относится к декабрю 2005 и якобы упоминается в запросе #8379426 (Support Request Incident), но на случай, если кто-то столкнется или если ссылка похерится, приведу описание здесь в вольном переводе.

D. Higi
Среда, 21 дек 2005 00:02:13 -0800
См. существующий запрос в техподдержку #8379426

ДЕЙСТВИЕ:
Запущенная проверка целостности длится слишком долго (до нескольких дней).

РЕЗУЛЬТАТ:
Система будет заблокирована на это время.

ПРИЧИНА:
Проблема кроется в методе SysConsistencyCheck.kernelCheckRecords(), где после выполнения pack/unpack над объектом Query теряется отношение (relation) [между таблицами]. После этого все записи InventTable будут объединены (joined) со всеми записями InventTxt.
При динамическом создании запроса методы SysQuery::countLoops() и SysQuery::countTotal() расчитывают неверное количество записей. Это происходит из-за потери отношений (relations) между таблицами в методе SysQuery::countPrim(). Такого не происходит в случае статических запросов.
Запуск проверки целостности на запасах номенклатуры в наличии может занять слишком длительное время или даже привести к критической ошибке в Microsoft Axapta из-за того, что totalCount в градуснике (Progress) диалогового окна неправильно вычисляется в методе SysQuery::countTotal().

РЕШЕНИЕ:
В Classes\SysQuery была добавлена установка свойства QueryBuildDataSource.Relations в true вместо следующей последовательности вызовов:
DictRelation.loadTableRelation(tableId),
QueryBuildDataSource.addRelation(DictRelation);

Результат действия этих двух вызовов - создание отношения (relation) с указанной таблицей. Такое же поведение реализовано и на уровне ядра.

Код до изменений (\Classes\SysQuery):
X++:
public static Query addTableRelation(Query query, tableId tableId)
{
    Query retQuery = new Query(query.pack());
    QueryBuildDataSource qbds1;
    QueryBuildDataSource qbds2;
    DictRelation dr;

    qbds1 = retQuery.dataSourceNo(1);
    qbds2 = qbds1.addDataSource(tableId);

    dr = new DictRelation(tableId);
    dr.loadTableRelation(qbds1.table());

    qbds2.addRelation(dr);

    return retQuery;
}
Код после изменений (\Classes\SysQuery):
X++:
public static Query addTableRelation(Query query, tableId tableId)
{
    Query retQuery = new Query(query.pack());
    QueryBuildDataSource qbds1;
    QueryBuildDataSource qbds2;

    qbds1 = retQuery.dataSourceNo(1);
    qbds2 = qbds1.addDataSource(tableId);

    qbds2.relations(true);

    return retQuery;
}

Последний раз редактировалось gl00mie; 06.09.2006 в 15:06.