Коллеги, что вы думаете о данном коде? 2MikeR

[belugin]

Цитата:

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

. То есть оптимистическая абортирует затормозившие процессы, без стыда и совести.

В этом случае предлагается повторить транзакцию.

У тебя свое определение целостности.

http://en.m.wikipedia.org/wiki/Consi...tabase_systems)

In database systems, a consistent transaction is one that starts with a database in a consistent state and ends with the database in a consistent state. Consistent state means that there is no violation of any integrity constraints. Consistency may temporarily be violated during execution of the transaction, but must be corrected before changes are permanently committed to the database. If the transaction would leave the database in an illegal state, it is aborted and an error is reported.[1]

[MikeR]

Итого резюмируя, как же все таки сделать озвученный код оптимальнее и с минимальными затратами, а так же с учетом фич, которые появились в AX 2012.

While select InvGuid, ParentInvGUID,recId from current WHERE current.InvGuid == InvGUID
        Join RecId from parent WHERE parent.InvGUID  == current.ParentInvGUID
{

            SELECT FIRSTONLY RecId, AMOUNTCUR from 
            parentDistr
            WHERE parentDistr.InvGUID == InvGUID &&
                parentDistr.TransRecId == inventoryGuidInvoice.TransRecId
                //...........
                && parentDistr.JuridicalPersonId == inventoryGuidInvoice.JuridicalPersonId;
//...........
            if(parentDistr.RecId)
            {
                update_recordset parentDistrUpd
                setting 
 parentDistrUpd.AMOUNTCUR += inventoryGuidInvoice.AmountCur;//слияние к предку
            }
            else
            {
                RecordInsertList.add(InventoryGuidInvoice);
            }
    }

Далее просто

RecordInsertList.insertDatabase();

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

Я вообще считаю, что циклы должны быть конечными при любом раскладе, любое использование обратного приводит к некоторой расхлябанности в коде и как следствие падению производительности. Пусть лучше разработчик доказывает, что необходимо использовать именно while(true), чем закрывать на это глаза с самого начала. В принципе правильно спланированное приложение позволит выполнять запросы без while(true) и Left Join, на самом деле это уже вопрос более к архитектору приложения, нежели к разработчику. Про использование fieldList, соединений таблиц не говорю, так как этого полно можно прочитать в тренингах.

PS Да и всеж таки код с таблицами tempDB будет с точки зрения целостности, за которую идет война не одну страницу, будет более правильным, в одной транзакции одной операцией. Единственный минус - создание дополнительных объектов в репозитарии.
И не надо ждать ночи на пакетные задания