Загадочные пропажи шапок журналов

[Corel]

DAX 2009 Rollup 7

Изредка (раз 5 в день) наблюдается очень странная вещь: создаваемый программным кодом складской журнал (InventJournalTable) бесследно пропадает, при этом строки его остаются. Под "бесследно" имеется ввиду, что его следов нет в SysDatabaseLog. Строки его создаются в той же транзакции, но остаются на месте: когда подсовываешь им новую шапку, всё становится как надо.

Я даже сделал таблицу-дубль, в которую пишу всё содержание InventJournalTable в методе Application\ttsnotifyCommit(), и туда действительно всё пишется, оттуда хотя бы восстанавливать можно пропавшие данные. Но сама по себе ситуация напрягает.

Есть идеи, что это может быть, или, по крайней мере, как это поймать?

[rudi]

Проверь, что у тебя ошибки вида Exception::UpdateConflict или Exception::Deadlock не вызывают повторное создание журнала без создания шапки журнала.

[fed]

Я такие ситуации лечу дописыванием watchdog-кода в InventUpdateOnHand. Поскольку там логируется список всех измененных inventTrans, можно дописать новый тип 'как бы проверки' в inventSumDeltaDim. Потом при завершении транзакции можно написать запросик, который проверяет наличие складских журналов (конечно только по тем аналитикам и номенклатурам, которые обновлялись в текущей транзакции), у которых нету шапки. Проверка эта должна включаться/выключаться по какому-то глобальному параметру.
Потом ждем пока пользователь позвонит и пожалуется на непонятное сообщение. Дальше быстренько спрашиваем пользователя чего он такого делал и трассируем ситуацию сами. После достижения ясности можно этот watchdog отключить и попытаться исправить код, из за которого ошибка случается.

И так до следующего watchdog Можно конечно вообще в Application.ttsNotifyPreCommit поставить тупую проверку на все журналы без заголовков. Просто во многих случаях, проверка целостности вообще всех данных занимает очень много времени и нету возможности ее использовать. А при фильтрации по inventumDeltaDim для текущей сессии, все-таки удается проверяемое множество локализовать и время проверки опустить до разумных значений...

[mazzy]

Цитата:

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

...странная вещь ... имеется ввиду, что его следов нет в SysDatabaseLog.

ничего странного.
какой-то нехороший редиска-программист вызывает doDelete. или перед delete skip-метод.

скорее всего, будет оправдываться тем, что "так работает быстрее". бгггг.

ищите в коде.

[mazzy]

Цитата:

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

Проверь, что у тебя ошибки вида Exception::UpdateConflict или Exception:eadlock не вызывают повторное создание журнала без создания шапки журнала.

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

[TasmanianDevil]

Цитата:

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

ничего странного.
какой-то нехороший редиска-программист вызывает doDelete

Попадает он в журнализацию.
Про skip'ы не помню точно результаты экспериментов, но тоже кажись не обходит и отлавливается журнализацией.

[Logger]

Вроде была похожая ситуация в трешке еще. И был исправляющий хотфикс.
В некоторых случаях когда при создании складского журнала был фильтр по шапке, то ядро меняло значение journalId на другое.
Т.е. шапка не терялась и не удалялась. Значение номера журнала перескакивало на другое, а строчки сами по себе оставались. Что именно исправлял хотфикс - не помню.

Поищите, возможно как раз ваш случай.

[Corel]

Цитата:

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

ничего странного.
какой-то нехороший редиска-программист вызывает doDelete. или перед delete skip-метод.

скорее всего, будет оправдываться тем, что "так работает быстрее". бгггг.

ищите в коде.

В том-то и дело, что происходит это не в каком-то особом методе, вызываемом отдельно, а либо в пакетниках, штампующих такие журналы сотнями в день, либо при стандартных действиях пользователя по движению товара. И происходит далеко не всегда. В мой лог записывается call-stack и никаких вызовов левых методов в нём не видно.

То есть, пока что это выглядит так:

ttsbegin;
//***
inventJournalTable.insert();
//***
{
   inventJournaltrans.JournalId = inventJournalTable.JournalId;
   //***
   inventJournaltrans.insert();
}
ttscommit;

И изредка этот механизм сбоит так, что inventJournalTable на выходе нет, а все созданные inventJournaltrans на месте.

[S.Kuskov]

Цитата:

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

Попадает он в журнализацию.
Про skip'ы не помню точно результаты экспериментов, но тоже кажись не обходит и отлавливается журнализацией.

doXXXX методы однозначно не логируются. В случае skip* методов возможны варианты: Вопрос про skipDeleteMethod

[gl00mie]

Из моего скромного опыта, doXXXX-методы не логируюся в журнал БД только в случае предварительного успешного вызова skipDatabaseLog(), иначе - логируются, как и обычные CUD-операции.

[S.Kuskov]

Действительно. TasmanianDevil, gl00mie - ваша правда.

[TasmanianDevil]

Только что проверил

static void Job387(Args _args)
{
    LedgerTable ledger;
    
    ;
    
    ttsbegin;
    
    ledger = LedgerTable::find('test', true);
    
    if(ledger.skipDatabaseLog(true))
        ledger.doDelete();
    
    ttscommit;
}

Удаляется и отлавливается в журнализации

[Logger]

В 2009-й вроде как еще была бага, что журналирование надо было настраивать в каждом домене.
Так что если журналирование настроили для домена Admin а у пользователя права есть только в другом домене а в admin ничего нет то аксапта считает что журналирование к этому пользователю никакого отношения не имеет и записи в sysDatabaselog не пишет !

[gl00mie]

LedgerTable - не самая удачная таблица для экспериментов Если, опять же, обратиться к книге Inside Dynamics AX 2009, то в 12-й главе читаем:

Цитата:

If a table is not entire-table cached, however, you can avoid any downgrade caused by the previously mentioned functionality.

LedgerTable в 2009-й как раз кэшируется полностью. Я провел эксперимент на CustTransIdRef - там у меня skipDatabaseLog() успешно отключает логирование в журнал БД.

[TasmanianDevil]

Фиг с ними, с нюансами журнализации удаления - другая мысль, весьма идиотского плана, есть.
Лог по Insert'у у пропащих журналов есть ?

[someOne]

Цитата:

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

Вроде была похожая ситуация в трешке еще. И был исправляющий хотфикс.
В некоторых случаях когда при создании складского журнала был фильтр по шапке, то ядро меняло значение journalId на другое.
Т.е. шапка не терялась и не удалялась. Значение номера журнала перескакивало на другое, а строчки сами по себе оставались. Что именно исправлял хотфикс - не помню.

Поищите, возможно как раз ваш случай.

Да, такая ситуация регулярно повторялась, еще начиная с трешки, до 2009 включительно!

Помогает такое вставить в начало метода в таблице InventJournalTable

public void update()
{
    ;
    // bug fix -->
    if (this.JournalId != this.orig().JournalId)
    {
        throw error("Попытка изменить номер складского журнала - " + this.JournalId);
    }
    // bug fix <--
....

Попробуйте - помогает, проверено!