The daily Axapta WTF

[kashperuk]

Цитата:

Сообщение от 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 больше нет.
Может этот код где-то и существует, но я не имею ни малейшего представления, где это сейчас.

[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]

Цитата:

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

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

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

[SRF]

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

[kashperuk]

Цитата:

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

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

Сергей, вы у себя это починили? Или это теоретическая находка?

[SRF]

Починили, добавили индекс по LoadLineRecId и код слегка поправили, не знаю уж какая в итоге была задумка начального запроса, но правили вот так:

    select count(RecId) from segmentLine
        //join line
        where segmentLine.LoadLineRecId == loadLine.RecId;

[S.Kuskov]

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

[SRF]

О том и речь, зачем.

[b_nosoff]

RetailTransactionServiceOrders::updateCustomerOrder()

    salesLine.SalesQty = qty;
    salesLine.QtyOrdered = qty;

[b_nosoff]

И еще прикольный косяк - в RetailOrderHistoryViewQuery на датасорсе RetailTransactionTable, присоединенном к SalesTable по notexists join, не хватает условия по EntryStatus != Voided, приводящий к тому, что если вы отменили транзакцию по какому-либо из Customer Order-ов, он пропадает из истории на POS.
Вообще, про это условие, похоже, не все помнят. Вот, например, в RetailTransactionServiceTransactions::addSalesOrderToResultMap() тоже забыли...

[kashperuk]

Цитата:

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

RetailTransactionServiceOrders::updateCustomerOrder()

    salesLine.SalesQty = qty;
    salesLine.QtyOrdered = qty;

Такого кода в 7ке нету в этом классе

[b_nosoff]

Цитата:

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

Такого кода в 7ке нету в этом классе

В 2012 R3 CU12 есть

[S.Kuskov]

А сам способ проверки наличия в таблице записей через подсчёт их количества это же неаккуратненько как-то.

[kashperuk]

Цитата:

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

А сам способ проверки наличия в таблице записей через подсчёт их количества это же неаккуратненько как-то.

Да, я в фиксе сделал просто firstonly RecId вместо count()

Retail запрос тоже пофиксил.

[Raven Melancholic]

Я не работаю с DAX2012 и не специализируюсь на retail в предыдущих версиях.
Для собственного развития время от времени копаюсь в DAX2012. Такое впечатление, что куча мест, касающихся retail в DAX2012 это тема для daily Axapta WTF.
Почему так? В предыдущих версиях для России в основе лежало решение от Коламбуся для конкретного клиента (могу ошибаться, но вроде бы для Перекрестка). В DAX2012 было заявлено, что решение для ритейла универсальное международное. Думаю, что "международное решение" это как-то выверенное на сотнях-тысячах клиентов. Что не так в "международном решении"?

[Ivanhoe]

Это когда было решение коламбуса по ритейлу в стандарте?
А модуль ритейл, насколько я знаю, был куплен у международного партнера еще для 2009, а в 2012 его уже мс сам переписывал.

[b_nosoff]

Цитата:

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

А модуль ритейл, насколько я знаю, был куплен у международного партнера еще для 2009, а в 2012 его уже мс сам переписывал.

Да, верно, модуль был куплен у LS Retail для 2009-й версии

[trud]

Оригинально подошли к проблеме переименования полей в D365. При переименовании поля в таблице и нажатии кнопки сохранить старое просто удаляется, а новое создается. Проблема ID наконец-то решена(о чем вроде как даже писали в what's new)
Правда данные при этом тоже удаляются, но кого это волнует.

[Vadik]

Цитата:

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

Проблема ID наконец-то решена

Heavy is good. Heavy is reliable (c) Борис Бритва
Особенно удобно при рефакторинге, не правда ли ?