The daily Axapta WTF - Страница 17 - Курилка

gl00mie · 27.10.2018, 10:43

PurchTotals "переопределить" можно, другое дело, что это нужно делать "иногда". Подобные места все чаще приходится лечить с помощью Option 3. Disposable context, в данном случае: где-то вышле по стеку создать singleton-"флажок", а где-то ниже, скажем, в постобработчике создания PurchTotals, по флажку подпихивать класс-пустышку вместо реального класса расчета итогов. Но выглядит это все очень извратно на фоне нормальных ветвлений в коде, которые можно было делать прежде.

skuull · 27.10.2018, 10:52

Там вообще все плохо с purchline, есть в ГЛ параметрах галка, обрабатывать сабледжер параллельно и из-за нее purchline на апдейте tax сама себя лочит...

dech · 20.11.2018, 15:34

AX 2012 R3. В методе SysDictIndex.showDuplicates() неверно формируется список ORDER BY. Иначе говоря, если подсунуть индекс InventDim.DimIdx, у которого отключены некоторые поля, то неверно составленный запрос вызовет ошибку.
Вместо

X++:

stmtStr += int2str(enabledFields[i]+1);

необходимо указать непрерывную последовательность чисел:

X++:

stmtStr += int2str(i+1);

dech · 21.11.2018, 09:44

Ну и такая же байда с ResultSet, если количество фактических полей не совпадает с описанным, выбирается getString(12) при том, что в SELECT-е участвовало всего 10 полей.

AlexSD · 20.12.2018, 22:07

D365 FO
public class InventItemInventoryDimensionStorageDimConversionTaskInitiatorDelegateHandlers
{
}

В одном имени два раза использованы слова Inventory и Dimension... При Балмере такого не было...
Кто-нибудь натыкался на доку, по каким критериям оценивать таблицы с InventDimId, нужен им конвертер или нет?

axm2017 · 14.01.2019, 10:55

Есть все таки в Ax какие то традиции переходящие имхо из поколение в поколения.
RunBase

X++:

public QueryRun queryRun()
    {
        return null;

    #if.never
        return QR;
    #endif
    }

И в 12 и в 365 соответственно

**sukhanchik** · 14.01.2019, 15:09

Хорошие традиции. Несут в себе документацию, что в этом методе надо возвращать переменную QR, определенную в ClassDeclaration наследника RunBase.
Т.е. это документирование того, как надо использовать фреймворк.

axm2017 · 14.01.2019, 16:36

Цитата:

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

Хорошие традиции.

Хорошая традиция это писать документацию в комментариях.
Здесь же то, от чего так радуются разрабы с обычных проектов, не знающие о своем отдельном пути фреймворководства.

Stitch_MS · 10.02.2019, 11:02

Logger · 10.02.2019, 11:59

Этот код вывел 16?
Арифметика неверно считает?

**mazzy** · 10.02.2019, 12:43

Цитата:

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

Этот код вывел 16?
Арифметика неверно считает?

почему сразу "неверно"?
очевидно, что сейчас так записывается битовый сдвиг осьмерки влево на единицу.

Stitch_MS · 10.02.2019, 13:48

Цитата:

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

Этот код вывел 16?
Арифметика неверно считает?

При Балмере такого не было.

db · 10.02.2019, 14:26

Цитата:

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

При Балмере такого не было.

да ладно

вот хит на все времена Проверка на RecId

db · 10.02.2019, 14:16

арифметика не при чем. проблема в реализации case с множественными значениями. если в в такой ветке нет break, то код ветки выполняется столько раз, сколько значений в списке

вот так работает нормально

X++:

    public static void main(Args _args)
    {       
        int i = 1;
        int j = 0;
 
        switch (i)
        {
            case 1:
            case 2,3,4:
                Info("!!");
                j+=8;
                break;
        }
        Info(int2Str(j));
    }

а если убрать break, то выведет 24

а вот так вообще 32:

X++:

   public static void main(Args _args)
    {       
        int i = 1;
        int j = 0;
 
        switch (i)
        {
            case 1, 2,3,4:
                Info("!!");
                j+=8;
        }
        Info(int2Str(j));
    }

где то слышал (так что может и вру) что в IL то ли отсутствует, то ли какая то особенная реализация fall-through - исполнения в switch веток case друг за другом если нет break. Вероятно здесь пытались как то реализовать стандартное X++ поведение switch на особенностях IL и малость перестарались/недосарались в случае с множественными значениями

AlGol · 14.02.2019, 10:34

DAX 2012 R3

При переименовании кода складского журнала через паспорт записи не меняется код журнала в InventTransOriginJournalTrans.InventJournalId и в InventTransOrigin.ReferenceId.

В результате, разнести нормально такой журнал не получается.
Плюс - удаление такого журнала оставляет складские проводки Заказано в базе, хотя строки журнала удаляются.

Ivanhoe · 14.02.2019, 10:52

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

AlGol · 14.02.2019, 17:23

Цитата:

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

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

Хорошая функция (была). Правильная. И пользовались ею часто, может не на этапе обычной эксплуатации а при первоначальном вводе данных или массовых перетасовках данных.
Но похоже, если взят курс на замену натуральных ключей суррогатными, то её время подходит к концу.

**Vadik** · 27.02.2019, 17:27

Давным-давно, один мальчик установил KB4492562, и все инвойсы стали показывать 4.67. Никто так и не смог разобраться, правильно это было или нет

**fed** · 12.03.2019, 15:50

Версия 8.1.3, метод SSRSReportRunController.CheckBatchJobStatus() содержит следующий замечательный код:

X++:

                UserConnection userConnection;
                try
                {
                    userConnection = new UserConnection();
                    userConnection.ttsbegin();
                    // Update teh batch job status to 'Waiting'
                    select pessimisticLock firstonly * from batchJobUpdate where batchJob.RecId == batchJobUpdate.RecId;

                    if (batchJobUpdate)
                    {
                        batchJobUpdate.Status = BatchStatus::Waiting;
                        batchJobUpdate.update();
                    }

                    userConnection.ttscommit();
                }
                finally
                {
                    userConnection.finalize();
                }

Где-то после 8.1.1, при любой печати отчета, система проверяет что в системе присутствует специальный батч, который там что-то очищает и каким-то hausekeeping занимается. Проблема в том, что если этот батч когда-то был создан, а потом ушел в ошибку или в canceled, то при любой попытке печати любого отчета вы получите сообщение о том что система не может обновить запись в BatchJob, поскольку она не была выбрана в рамках транзакции. (Просто авторы кода забыли написать batchJobUpdate.setConnection(userConnection)).
Лечится это достаточно простым путем: Надо найти в вашей системе батч с именем "Report Data Cleanup" и просто его удалить. При следущей печати отчета, система прокашляется и создаст нужный батч.

ax_mct · 12.03.2019, 18:55

Цитата:

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

Версия 8.1.3, метод SSRSReportRunController.CheckBatchJobStatus()
...
поскольку она не была выбрана в рамках транзакции. (Просто авторы кода забыли написать batchJobUpdate.setConnection(userConnection)).

Дык update есть, а select for update - там нет. Разве не забыли "for update"?
Или там насквозь хитрый batchJobUpdate.update() который сам себе write() ?

если писать batchJobUpdate.setConnection(userConnection)) то это скроет ошибку за счет нового соединения. Так?