Висящие проводки

[NNB]

Добрый день
Изредка, в результате непонятно каких действий пользователей создается след. ситуация:
в InventTrans появляются проводки у которых StatusIssue - 'Физ. зарезервировано' и TransRefId ссылаются на некий журнал переноса.
В журнале переноса соответствующие строчки были удалены.
Методы на таблицах не менялись, да и, в любом случае, ошибка появляется только изредка.
Перезагрузок не было.
У кого есть какие мысли?
Заранее спасибо

[andrewK]

Может быть строки журнала не удаляются, а происходит переименование кода журнала?
Ссылка на обсуждение

[ashu]

Кстати, довольно частая проблема. Причем начиная с версии 3.0 и вплоть до 5 встречался с разными ее вариациями.
Воспроизвести (и понять полностью) в чем причина, ни как не удавалось (хотя особо и не старались), кроме двух вариантов (которые не всегда срабатывали, только если было определенное сочетание фазы луны, давления, делал это пользователь или конс ,а не программист в дебагере и тд):
1. при удалении строк складского журнала, прерывать процедуру.
2. удаление шапки складского журнала

кроме ситуации когда реально нет строк журнала, но есть запись в инвенттранс, наиболее часто встречалась когда нет самого журнала (шапки), а есть записи строк, и соответственно инветтрансы, что тоже не гуд.

на эти случаи были простенькие джобики, которые такие случаи находили и/или исправляли, потому с такими моментами особого не парились и не уделяли внимание

[NNB]

Особой проблемы конечно нет, но интересно

[Ace of Database]

Попробуйте следующие варианты:
1) Включите в журнале базы данных логирование удаления, обновления и переименования складских журналов. Потом, когда обнаружите зависшую проводку, из поля TransRefId проводки возьмите номер журнала. Найдите историю изменений этого журнала в журнале базе данных. Для анализа истории изменений полезно сделать небольшую модифу, которая при вставке записи в таблицу SysDatabaseLog заполняет созданное вами строковое поле стеком вызова, из которого произошло удаление или переименование журнала. Это чтобы понять, каким образом журнал исчез. В методе insert() таблицы SysDatabaseLog вставьте строку

this.Callstack = this.stackTraceStr(xSession::xppCallStack());

где Callstack - добавленное новое поле длиной 1000 символов.

На форму отображения истории журнала базы данных SysDatabaseLog выведете это текстовое поле.

2) Проверьте, не модифицирован ли у вас класс InventUpd_DeleteMovement, который отвечает за удаление складских проводок. Сравните изменения в слоях для этого класса. Проверьте, заполнены ли у зависших проводок поля TransChildType, TransChildRefId. Если поля заполнены, то это тоже подозрительно.

3) Проверьте метод delete в таблице InventJournaltrans. Он должен содержать такие строки для AX2009:

    InventUpd_DeleteMovement::newMovement(InventMovement::construct(this)).updateNow();
    if (this.JournalType == InventJournalType::Transfer && this.ToInventTransId && this.ToInventTransId != this.InventTransId)
    {        InventUpd_DeleteMovement::newMovement(InventMovement::construct(this,InventMovSubType::TransferReceipt)).updateNow();
    }

4) Через SQL Managemet Studio прямым запросом SQL проверьте, не остались ли в базе строки по журналу. Строки могут быть не видны на форме в Аксапте (например, удалили InventDim, на который ссылается строка журнала)

select * from InventJournalTrans where JournalId like '%10021234'

like нужен, если для journalId включено выравнивание вправо

5) Запросом SQL проверьте, не остался ли в базе сам журнал. Журнал может быть не виден на форме по разным причинам.

select * from InventJournalTable where JournalId like '%10021234'

[Ace of Database]

Ну и на InventJournaltrans поставьте логирование изменений и удалений.

[Ace of Database]

Вот код метода stackTraceStr который у меня добавлен в таблице SysDatabaseLog

str stackTraceStr(container stackTrace)
{
    int i;
    str s="";
    ;
    for(i = 7; i<=conLen(stackTrace); i+=2)
        s+=strFmt("%1:%2\r\n", conPeek(stackTrace, i), conPeek(stackTrace, i+1));

    return s;
}

[Ace of Database]

Цитата:

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

наиболее часто встречалась когда нет самого журнала (шапки), а есть записи строк, и соответственно инветтрансы, что тоже не гуд.

Проверьте, что у вас на таблице InventJournalTable в узле DeleteActions добавлена таблица InventJournalTrans, и для нее включен каскад. В стандарте по умолчанию все включено.

[Ace of Database]

Анализ истории удаления журнала или строк журнала нужен, чтобы определить, не удаляются ли где-то строки или сам журнал через вызов doDelete()

[Ace of Database]

Еще можно проверить, не менялся ли InventTransId в строке журнала в процессе ее жизни до удаления. Это совсем параноидальная проверка, но если зависают проводки, то почему бы и нет.
В стандарте изменения уже присвоенного InventTransId нигде нет. Но если у вас работало много программистов на большом навороченном проекте, то все может быть