The daily Axapta WTF

[kashperuk]

Quote:

Originally Posted by kashperuk

RAMESH кстати уже давно у нас не работает.
Но комменты, похоже, до сих пор остались

А теперь их уже нет
Точнее, в Platform Update 3 их уже не будет

Магия

[AlGol]

Обратите внимание на очень неприятную особенность работы catch:
https://blogs.msdn.microsoft.com/mfp...4/x-the-catch/

[gl00mie]

Это скорее неприятная особенность определенного способа обработки исключений, который практикуют некоторые отступники от Best Practices

[AlGol]

AX2012R3
Понадобилось сделать View, в котором должна отображаться одна запись с максимальным значением определенного поля.
Делаю в АОТ Query, с одним источником данных, задаю сортировку по нужному полю, в параметрах источника пишу свойство FirstOnly = Yes.
Делаю в АОТ View, на основании созданного query.
Открываю посмотреть что получилось - и вижу все записи таблицы.

В результате разбора выяснил, что View не обращает внимания на опцию FirstOnly в Query.
Пришлось делать обходной маневр в виде двух view с получением max поля и потом отфильтровывать по нему данные.

[SRF]

Quote:

Originally Posted by AlGol

В результате разбора выяснил, что View не обращает внимания на опцию FirstOnly в Query.

Это проблема не view, а игнорирование опции firstOnly в Query dynamicsaxhints: Query datasource FirstOnly property

[AlGol]

Quote:

Originally Posted by SRF

Это проблема не view, а игнорирование опции firstOnly в Query dynamicsaxhints: Query datasource FirstOnly property

что-то я не уловил в приведенном посте один момент: каким образом выполнялась трансляция Query в SQL запрос ( в местах где написано "The query is translated into SQL Server query").

Но по большому счету, именно в применении к данной проблеме, мне неинтересны ньюансы формирования запросов на SQL. Я хочу чтобы если в запросе установлен хинт FirstOnly то он бы возвращал одну запись.

Через X++ все так и происходит, я получаю одну запись. Если я делаю форму где структура источников формируется на основании Query тоже вижу поддержку Firstonly.

При реализации View посредством Query, это свойство просто игнорируется.

[SRF]

Quote:

Originally Posted by AlGol

что-то я не уловил в приведенном посте один момент: каким образом выполнялась трансляция Query в SQL запрос ( в местах где написано "The query is translated into SQL Server query").

Обычным, когда пытаетесь выполнить указанный запрос с хинтом firstOnly, на SQL сервер уходит запрос без него, можно например в журнале трассировки запросов посмотреть.

Quote:

Originally Posted by AlGol

Но по большому счету, именно в применении к данной проблеме, мне неинтересны ньюансы формирования запросов на SQL. Я хочу чтобы если в запросе установлен хинт FirstOnly то он бы возвращал одну запись.

Через X++ все так и происходит, я получаю одну запись. Если я делаю форму где структура источников формируется на основании Query тоже вижу поддержку Firstonly.

При реализации View посредством Query, это свойство просто игнорируется.

View это просто частный случай общей проблемы, в форме и X++ работает, потому что отсекает ядро AX(в действительности же на SQL запрос уходит другой), View же объект SQL, который создан на основании ошибочного запроса.

[trud]

Из индусского - типа все бест-практис соблюдены

   if (custInvoiceJour.company() == "@LIN103")                 
   {
        if(CustInvoiceJour.CurrencyCode == "@LIN63")               
        {
            bankName = strfmt("%1 %2","@LIN73","@LIN104");  
        }

[Maxim Gorbunov]

AX2012 R3 CU12 (6.3.5000.133)
(встречается начиная с AX2012 R3 RTM)

\Data Dictionary\Tables\WHSWorkTable\Methods\lockUnlockWork

public static void lockUnlockWork(WHSWorkId _workId, WHSUserId _userId)
{
    WHSWorkLine             workLine;
    WHSDimTracking          dimTracking;
    ...

    #localmacro.WorkLineFieldsToResetStatus
        WorkStatus                  = WHSWorkStatus::Open,
        UserId                      = '',
        WorkInProcessUTCDateTime    = utcDateTimeNull(),
        AskForNewLicensePlate       = NoYes::No
    #endmacro

    #localmacro.WorkLineStatusInProcessButNotStarted
        workLine.WorkId == _workId
        && workLine.WorkStatus == WHSWorkStatus::InProcess
        && workLine.QtyWork == workLine.QtyRemain
    #endmacro

    ...

    // If we already have some work finished, we only reset the InProcess work lines,
    // where no actual work has been performed so far

    update_recordset workLine
        setting #WorkLineFieldsToResetStatus
        where #WorkLineStatusInProcessButNotStarted;

    if (workTable.isWorkTransTypeOutbound())
    {
        delete_from dimTracking
            exists join workLine
            where #WorkLineStatusInProcessButNotStarted
               && dimTracking.WorkId == workLine.WorkId
               && dimTracking.LineNum == workLine.LineNum
               && dimTracking.Processed == NoYes::No;
    }
    ...

}

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

    update_recordset workLine
        setting WorkStatus                  = WHSWorkStatus::Open,      // <-- (1)
                UserId                      = '',
                WorkInProcessUTCDateTime    = utcDateTimeNull(),
                AskForNewLicensePlate       = NoYes::No
        where workLine.WorkId == _workId
           && workLine.WorkStatus == WHSWorkStatus::InProcess           // <-- (2)
           && workLine.QtyWork == workLine.QtyRemain;

    if (workTable.isWorkTransTypeOutbound())
    {
        delete_from dimTracking
            exists join workLine
            where workLine.WorkId == _workId
               && workLine.WorkStatus == WHSWorkStatus::InProcess       // <-- (3)
               && workLine.QtyWork == workLine.QtyRemain
               && dimTracking.WorkId == workLine.WorkId
               && dimTracking.LineNum == workLine.LineNum
               && dimTracking.Processed == NoYes::No;
    }

[Slava Chernenko]

Наткнулся на ошибку, полез смотреть откуда ноги растут, оказалось так всегда было, в смысле в SYS слое такой код.
AX 2009, EmplTable form, datasource EmplTable write():

public void write()
{
.....

    ttsbegin;

......

    if (emplTable.PartyId && dirPartyTable.Name && !DirPartyTable::exist(emplTable.PartyId))
    {
.......

        if (dirPartyTable.validateWrite())
        {
            // Create a new DirPartyTable row.
            dirPartyTable.write();
            lastNewUnusedId = "";
        }
        else
        {
            // Abort the transaction.
            ttsabort;
        }
    }
    else if (emplTable.PartyId && dirPartyTable.Name && dirPartyTableChanged && DirPartyTable::exist(emplTable.PartyId))
    {
        if (dirPartyTable.validateWrite())
        {
            // Update the existing DirPartyTable row.
            dirPartyTable.write();
        }
        else
        {
            // Abort the transaction.
            ttsabort;
        }
    }

    super();

.....

    ttscommit;
}

Проблема в комбинации ttsabort в середине кода и ttscommit в конце.
Интересно, куда этот код разползся в следующих версиях и выжил ли в AX 7...

[kashperuk]

Quote:

Originally Posted by Slava Chernenko

Наткнулся на ошибку, полез смотреть откуда ноги растут, оказалось так всегда было, в смысле в SYS слое такой код.
AX 2009, EmplTable form, datasource EmplTable write():

public void write()
{
.....

    ttsbegin;

......

    if (emplTable.PartyId && dirPartyTable.Name && !DirPartyTable::exist(emplTable.PartyId))
    {
.......

        if (dirPartyTable.validateWrite())
        {
            // Create a new DirPartyTable row.
            dirPartyTable.write();
            lastNewUnusedId = "";
        }
        else
        {
            // Abort the transaction.
            ttsabort;
        }
    }
    else if (emplTable.PartyId && dirPartyTable.Name && dirPartyTableChanged && DirPartyTable::exist(emplTable.PartyId))
    {
        if (dirPartyTable.validateWrite())
        {
            // Update the existing DirPartyTable row.
            dirPartyTable.write();
        }
        else
        {
            // Abort the transaction.
            ttsabort;
        }
    }

    super();

.....

    ttscommit;
}

Проблема в комбинации ttsabort в середине кода и ttscommit в конце.
Интересно, куда этот код разползся в следующих версиях и выжил ли в AX 7...

EmplTable больше нет.
Может этот код где-то и существует, но я не имею ни малейшего представления, где это сейчас.

[pedrozzz]

AX 2012 R2
Десериализация структуры Struct::create(_container) в CIL, которая была упакована методом pack() в обычном исполняемом коде. Разъезжаются пары Ключ-Значение
Слева на скриншоте десериализация в обычном коде (ошибок нет), справа - выполненная в CIL. Как говорится, результат на лицо. Т.е. порядок значений в структуре остался прежним, а порядок ключей изменился.

[mazzy]

Quote:

Originally Posted by pedrozzz

AX 2012 R2
Десериализация структуры Struct::create(_container) в CIL, которая была упакована методом pack() в обычном исполняемом коде. Разъезжаются пары Ключ-Значение
Слева на скриншоте десериализация в обычном коде (ошибок нет), справа - выполненная в CIL. Как говорится, результат на лицо. Т.е. порядок значений в структуре остался прежним, а порядок ключей изменился.
Attachment 11188

оО!
1. спасибо
2. пожалуйста, зарегистрируйте багу. лучше от лица клиента. да, регистрация - это гемор. И очень сильный гемор. но эту - зарегистрируйте. пожалуйста.

и еще одно:
а можно попросить у вас еще и код, который у вас приводит к подобному "результату"?

[pedrozzz]

Quote:

Originally Posted by mazzy

2. пожалуйста, зарегистрируйте багу. лучше от лица клиента. да, регистрация - это гемор. И очень сильный гемор. но эту - зарегистрируйте. пожалуйста.

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

Quote:

Originally Posted by mazzy

а можно попросить у вас еще и код, который у вас приводит к подобному "результату"?

Сам код разбросан по кускам разных классов, которые в силу NDA я не имею права выкладывать. Но в целом идея такая:

1. Создаете в таблице YourTableName поле типа контейнер PackedData
2. Заполняете структуру значениями в обычном исполняемом коде и через .pack() сохраняете его в таблицу. Например так:
   

       YourTableName                           yourTableName;
       Struct                                  struct;
   
       struct  = new Struct();
       
       struct.add('ScenarioHistoryRecId', someRecId);
       struct.add('ResponseCode'        , someText);
       struct.add('InvoiceDateDispute'  , someDateTime);
       struct.add('OrigInvoiceDueDate'  , anotherDateTime);
       struct.add('OutstandingAmount'   , someRealValue);
       struct.add('DateReminderSent'    , oneMoreDateTime);
       struct.add('NewDueDateRemind'    , someDate);
       
       yourTableName.clear();
       yourTableName.PackedData = struct.pack();
       yourTableName.insert()

3. Создаете наследника RunBaseBatch, в методе run() десереализируете сохраненную структуру через create() и запускаете один раз просто так, а второй раз в пакете.
   

       YourTableName                           yourTableName = YourTableName::find(yourTableRecId);
       Struct                                  dataStruct    = yourTableName.PackedData
                                                             ? Struct::create(yourTableName.PackedData)
                                                             : new Struct();
       Counter                                 i;
   
       info(strFmt("Record id: %1", yourTableName.RecId));
       
       for (i = 1; i <= dataStruct.fields(); i++)
       {
           info(strFmt("%1: %2", dataStruct.fieldName(i), dataStruct.value(dataStruct.fieldName(i))));
       }

4. Удивляетесь увиденному

Похоже, что в AX ключи следуют в порядке их добавления, а в CIL в алфавитном порядке. Мне вот абсолютно на порядок плевать, но хотелось бы, раз они меняют порядок ключей, то чтобы и порядок значений изменился соответствующим образом. У нас R2, проверьте кто-нибудь в R3, может уже исправили.

[Stitch_MS]

Проверил в R3 CU11 - не исправили.

Чем отвечать на каверзные вопросы в регистрационной форме, я бы использовал Map, который вроде не глючит, если сделать так:

Запись

    map = new Map(Types::String, Types::Container);
    map.insert('ScenarioHistoryRecId', [123456789]);
    map.insert('ResponseCode'        , ['my text']);    
    packedMap = map.pack();

Считывание

    Map             map = Map::create(_packedMap);
    MapEnumerator   enumerator; 
    
    enumerator = map.getEnumerator();
    while (enumerator.moveNext())
    {
        info(strFmt("%1: %2", enumerator.currentKey(), conPeek(enumerator.currentValue(), 1)));
    }

[Ace of Database]

Вместо утренней зарядки, перед первым запуском Аксапты, быстро удаляем кеш на компьтере. В командной строке Windows вводим:
del /s ax*.auc

[gl00mie]

AX 2012 R3 \Classes\RetailTransactionServiceOrders\getCustomerOrder
AX 2012 R2 \Classes\RetailTransactionService\getCustomerOrder

select InventTransOrigin from inventTransOriginSalesLine
where inventTransOriginSalesLine.SalesLineInventTransId == salesLine.InventTransId;

Люди тестировали код, как обычно, на своей 10-гиговой игрушечной базе, и им было невдомек, что в кластерном индексе на первом месте стоит поле SalesLineDataAreaId - в итоге этот чудо запрос ни разу не попадает в индекс и на нормальных объемах данных приводит к зависанию на минуты. Из-за этого AX POS при попытке поднять заказ на продажу через RTS отваливается по таймауту. Если исправить на нормальный вызов InventTransOriginSalesLine::findInventTransOriginId(), то все отрабатывает за секунды.

[mazzy]

Quote:

Originally Posted by gl00mie

...приводит к зависанию на минуты...

ты лучше посмотри как поиск по номеру чека происходит...

[SRF]

AX 2012 R3, к словам об игрушечной базе Отсутствие индекса и непонятный cross join к WHSLoadLine.

[S.Kuskov]

А почему там джойнится курсор с именем Line, а условие накладывается на курсор с именем loadLine? Или там по смыслу так и нужно чтобы полное декартово произведение получалось?