отладка AX2012

[offenmeier]

отлаживаю проект в AX2012, не я писал.

новая форма, какие-то временные таблицы. по идее пользователь должен выбрать несколько записей на форме и они вставятся как misc charges к определённой строке PurchLine.

делаю, нажимаю ОК, получаю ошибку типа "Cannot edit a record in Purchase order lines (PurchLine).
An update conflict occurred due to another user process deleting the record or changing one or more fields in the record."

хорошо, делаю как сделал бы в 2009, ставлю брейкпойнт в классе Info в методе add чтобы узнать, откуда ноги растут. дебаггер ловит брейкпойнт, но в стеке самый нижний метод это PurchLine.Update()! не вызывается же update() на таблице сам по себе? ясно что я пойду длинным путём и посмотрю, что же в коде происходит на этой форме, которая не работает. но почему в дебаггере не видно, откуда вызывается update() на PurchLine???

исполнение бизнес-логики в CIL отключено.

[S.Kuskov]

Цитата:

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

дебаггер ловит брейкпойнт, но в стеке самый нижний метод это PurchLine.Update()! не вызывается же update() на таблице сам по себе?

Возможно обновление запускается в отдельном потоке?

[Dark Light]

Цитата:

Сообщение от S.Kuskov

Возможно обновление запускается в отдельном потоке?

или из внешней системы?

[driller]

Может там update_recordset/RecordSortedList используется, или что то подобное?
Вот этот способ должен помочь.

[Link]

Я такую картину видел при рекурсии. Т.е. если методы вызываются повторно, то они не дублируются в стеке, а перемещаются наверх списка.

[offenmeier]

посмотрел, что там делается на самом деле, а вызов там очень простой: update_recordset.

[ax_mct]

Цитата:

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

посмотрел, что там делается на самом деле, а вызов там очень простой: update_recordset.

Я бы избавился от update_recordset и вызывал reread.

[Logger]

Цитата:

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

Я такую картину видел при рекурсии. Т.е. если методы вызываются повторно, то они не дублируются в стеке, а перемещаются наверх списка.

Но реальный стек все равно можно увидеть
Рекурсия. Глюк отладчика.

[Dreadlock]

Буквально на днях делал Job для обновления PurchLine, и тоже заметил эту ошибку Пытался решить через:

while select forUpdate purchLine
{
    ....
    purchLine.update();
}

Не взлетело (

Помог вот такой код:

while select pessimisticLock purchLine
{
    ....
    purchLine.update();
}

Может и вам поможет

[Dodle]

I would use reread if I were you.

[Dreadlock]

But, I was me and you were you

[Владимир Максимов]

Конкретно для строк закупок проблема связана с модулем хранения версий закупок. Всякие PurchTableVersion, PurchTableHistory, PurchLineHistory...

Там может получиться так, что при обновлении первой строки закупки будет установлен признак IsModified для всех остальных строк этой же закупки. В результате и получаем конфликт обновления

Т.е., во-первых, ошибка "плавающая". Может быть, а может не быть. Во-вторых, первая строка всегда обновляется корректно. Проблема возникает при обновлении второй строки. Точнее, той порции строк, которые Axapta считывает "за раз" в свой кеш. И тут только reread() помогает

PS: Посмотрел, где же я на это натыкался. Ситуация обратная. Признак IsModifed снимается у всех строк вот в этом методе

\Classes\VersioningPurchaseOrder\archivePurchLine

Соответственно, можно во все циклы по PurchLine добавлять условие

        if (purchLine.IsModified)
        {
            purchLine.reread();
        }