Аудит блокировок

[Logger]

Ну я так и думал. Ваше исходное сообщение можно было понять словно из-за блокировок развалились InventSum и InventTrans. Как видно из примера ничего похожего и близко нет.

[miklenew]

Процитирую сам себя

Цитата:

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

A logger попросил пример.
Это пример с блокировками никак не связан.
Просто тема немного ушла.

Та была совсем другая история, она давно закрыта.

[Wamr]

Цитата:

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

Да у меня остатки расходятся с проводками.
Написал джобик он недолго работает 10 минут.
Раз в неделю запускаю 6-8 позиций исправляет.
Но надо решать эту проблему.
Есть подозрения что это из-за блокировок.

По первому предложению создается стойкое ощущение, что у вас InventSum != сумме InventTrans по полям ItemId & InventDimId.

Такое расхождение может возникнуть только при использовании doUpdate на InventTrans. Так как в update, insert, delete происходит обновление InventSum, то есть они всегда обновляются в паре.

Или я что-то опять не так понял?

[miklenew]

Цитата:

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

По первому предложению создается стойкое ощущение, что у вас InventSum != сумме InventTrans по полям ItemId & InventDimId.

Всё правильно.

Цитата:

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

Такое расхождение может возникнуть только при использовании doUpdate на InventTrans.

Я конечно поищу. Но всё же уже больше года работаю с этой прилагой и ламерских косяков в ней пока не встречал. Ошибки есть, я их исправляю, но не до такой же степени. В целом нормально, жить можно. Когда-то хорошую школу прошёл у человека, который учился у тебя. Сначала он у тебя, потом я у него.
Здесь степень модификаций (по формуле mazzy) даже чуть по меньше, чем у нас было на общем месте работы. Так что не привыкать.
Отвлёкся.

Цитата:

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

Так как в update, insert, delete происходит обновление InventSum, то есть они всегда обновляются в паре.
Или я что-то опять не так понял?

Всё правильно. Но классы то InventUpdate и InventMovement модифицированы, есть даже сильные утверждения, которые архитиктуры связей меняют. Сильно измененена связь InventTrans -> InventTransPosting.
Резервирование сильно переделано.
Блокировки я уже откинул.
Вчера сделал пересчёт InventSum. Сегодня появилось две позиции.
Причём по этим номенклатурам блокировок не было.
Буду дальше искать.
Эта проблема замечена была несколько месяцев назад.
Пересчёт InventSum-а раз в неделю помогал.
Просто текучки хватало. Щас посвободнее стало вот и решил пора искать.
Найду.

[raz]

Цитата:

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

Вчера сделал пересчёт InventSum. Сегодня появилось две позиции.

Если проблема так быстро проявляется, то рискну предложить вариант поиска.
Используем этот проект, включаем лог базы данных по всем операциям на InventTrans, через день отключаем лог, находим ошибочные позиции, смотрим по логу как это призошло.

[miklenew]

Цитата:

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

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

Спасибо. Классная штука.

[miklenew]

Нашёл.
Была форма о которой я даже и не знал.
Она делила строки журнала, в текущем уменьшала количество и выносила их в другой журнал.
Ошибка была когда количество из текущего журнала полностью выносилось в другой журнал.
В ней был такой код

              if (!inventTrans.Qty)
                  inventTrans.delete();
              else
                  inventTrans.update();

На первый взгляд безобидный.
Только при qty = 0 inventTrans удалялся, а InventSum не пересчитывался. Понятно почему, количество то ноль.
Сделал так

              if (!inventTrans.Qty)
              {
                  inventTrans.update();
                  inventTrans.delete();
              }
              else
                  inventTrans.update();

Ошибка исчезла.

[miklenew]

Спасибо ещё раз raz за проект.
Модераторам:
Почему тема с проектом raz-a не в Базе знаний?
Перенесите пожалуйста.

[Logger]

Цитата:

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

включаем на AOS-е опцию internal=comments (в 3.0 работает, как в других версиях - не знаю). Теперь запрос сохранится со значениями литералов (в комментариях)

Спасибо за ценную инфу. Очень не хватало такой информации. Правда при использовании обнаружил один баг. - Иногда такое логирование неверно отображает значение параметра.

Как обнаружил - накладывал фильтр по таблице по полю modifiedDate
фильтр такой

...Addrange(...).value(date2strXpp(systemDateGet()));

отладочная инфа показала что на оракл уходит запрос
AND (MODIFIEDDATE=:IN2/*1900/1/1*/)
а datasource(1).tostring() выдал строку
SELECT * FROM VendTable WHERE (((modifiedDate = TO_DATE('2009-02-27 00:00:00','YYYY-MM-DD HH24:MI:SS'))))

Реально же вернулась нужная строка. Так что получается что для определенных значений параметров логирование SQL-запросов может показать неверную информацию.

[ZVV]

Цитата:

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

Спасибо за ценную инфу. Очень не хватало такой информации.

ошибка update_recordset

Обратите внимание, что лучше таки использовать совместно с NOCURSORREUSE, т.к. иначе рискуете отловить не все запросы:

Цитата:

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

∙ -Internal=Comments
∙ This option will insert value of bind variables as comment into the
generated SQL statement; Therefore, this option will cause insertion of
an odd number of the character ‘ in a STR field to fail.

∙ -Internal=NoCursorReuse
∙ This option will force Axapta not to reuse internal database cursors;
therefore, if you want to examine the value of bind variable for all
traced SQL statements you must use this option in connection with the
‘–internal = Comments’.

Цитата:

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

Правда при использовании обнаружил один баг. - Иногда такое логирование неверно отображает значение параметра.
...

Странно, не сталкивался... Возможно причина в системных полях (MODIFIEDDATE)? Можете вложить примерчик?

[Logger]

Джобец

// GRD_fixQueryValue_pkoz    // pkoz 27.02.2009
static void Job463(Args _args)
{
    int         dd;
//    str         data;// = 27\02\2009;
    date        data = dateNull();
//    date        data = 27\02\2009;
    vendTable   vendTable;
    Query       Query;
    QueryRun    qr;

    str getRange()
    {
        ;
        //return date2strXpp(data);
        return
            strFMT( '((%1==%2))',
                        fieldStr(vendTable, modifiedDate),

                        //QueryValue(data) // с таким параметром кривая дата будет пр использовании расширенных запросов
                        date2strXpp(data) // а при таком все нормально
                        )
        ;
    }
    void qu(boolean _lit, boolean _ext, str _s)
    {
        boolean     good;
        ;
        //info("");
        Query = New Query();
        if (_lit)
            Query.literals(1);

        if (_ext)
            Query.addDataSource(tableNum(vendTable)).addRange(fieldNum(vendTable,
                //modifiedDate
                recId
                )).value(
                getRange()
                );
        else
            Query.addDataSource(tableNum(vendTable)).addRange(fieldNum(vendTable, modifiedDate)).value(QueryValue(data));

        info(Query.dataSourceNo(1).toString());
        qr = New QueryRun(Query);
        good = qr.next();
        info(strFMT("%3 Литералы %1, Расш запрос %2,  recId = %4", _lit, _ext, good ? "Есть результат" : "Нет результата", good ? qr.getNo(1).RecId : 0));
        info("");

        //info("");

    }
    ;
    setPrefix("Оператор SQL");
    info(getRange());

    //GRD_SqlTraceOn();
    //info("");

    qu(0, 0);
    qu(0, 1);
    qu(1, 0);
    qu(1, 1);
    //info("");
    //GRD_SqlTraceOff();

}

Как вы и предполагали, проблема связана с использованием -Internal=NoCursorReuse
Без использования этого ключа логирование может выдавать неверную информацию. modifiedDate - ни при чем

При изменении даты фильтрации

date        data = dateNull();

- логирование показывает значение которое использовалось в первый раз. Запрос на БД в любом случае правильный уходит.

[Logger]

Цитата:

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

Нашёл.
Была форма о которой я даже и не знал.
Она делила строки журнала, в текущем уменьшала количество и выносила их в другой журнал.
Ошибка была когда количество из текущего журнала полностью выносилось в другой журнал.
В ней был такой код

              if (!inventTrans.Qty)
                  inventTrans.delete();
              else
                  inventTrans.update();

На первый взгляд безобидный.
Только при qty = 0 inventTrans удалялся, а InventSum не пересчитывался. Понятно почему, количество то ноль.
Сделал так

              if (!inventTrans.Qty)
              {
                  inventTrans.update();
                  inventTrans.delete();
              }
              else
                  inventTrans.update();

Ошибка исчезла.

Ого !

Получается что в InventTrans.delete() есть ошибка.

Вместо вызова

        if (InventSum::mustInventTransBeUpdated(this))
        {
            inventSum = appl.inventUpdateTTSControl().inventSumSelectLocked(this);
            inventSum.updateInventTrans(this,NoYes::No);
        }

правильнее поставить

        if (InventSum::mustInventTransBeUpdated(this.orig()))
        {
            inventSum = appl.inventUpdateTTSControl().inventSumSelectLocked(this.orig());
            inventSum.updateInventTrans(this.orig(),NoYes::No);
        }

Потому что иначе легко развалить связку InventSum и InventTrans - что собственно и произошло в вашем примере. Сперва отредактировали количество в проводке, поняли что оно 0 и update() ни к чему - вызвали delete() и получили ошибку, там где не ожидали.

Delete() должен работать на основе значений которые лежат в базе, а не в текущем буфере.

В принципе нечто подобное сделано в методе inventTrans.update() - сперва из InventSum вычитаются значения this.orig() а затем прибавляются значения this. Нужно было код перенести убрав прибавку this но оставив вычитание this.orig() Т.е. автор InventTrans.delete() неявно заложился на то что удаляемый InventTrans перед удалением не редактировался.