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

Link · 30.03.2017, 00:37

Цитата:

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

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

Логично же, если не жалко хранить все данные в облаке, то значит и данные в кастомном поле не критичны. А может это еще одно ограничение в кастомизации приложения, зачем вам новые поля - пользуйтесь стандартными... ну или если очень нужно, просите МС добавить в стандард

**Vadik** · 30.03.2017, 16:36

Вынес часть сообщений в отдельную ветку, Как жить без средств разработки и отладки в продуктиве

skuull · 10.04.2017, 04:25

D365O 1611

X++:

driverLog = TMSDriverLog::find(appt.ApptId, true);
driverLog.ActualStartUTCDateTime = DateTimeUtil::utcNow();
driverLog.updateDates();
driverLog.update();

Зачем проверять что файнд что-то вернул ? Лучше покажем пользователю что запись никогда не была выбрана

И второй момент, на демо данных у LoadId и TMSApptId одна и та же номерная серия, поэтому вводя аппоинтмент АХ всегда находит сушествующий лоад который никакого отношения к делу не имееет, хотя хотелось бы аппоинтмент

X++:

case #CheckInOutId:
                if (mode == WHSWorkExecuteMode::DriverCheckIn || mode == WHSWorkExecuteMode::DriverCheckOut)
                {
                    if (WHSLoadTable::exist(_data))
                    {
                        fieldValues.insert(#CheckInOutId, _data);
                        fieldValues.insert(#LoadId, _data);
                    }
                    else if (WHSShipmentTable::exist(_data))
                    {
                        fieldValues.insert(#CheckInOutId, _data);
                        fieldValues.insert(#LoadId, WHSShipmentTable::find(_data).LoadId);
                    }
                    else if (TMSAppointment::exist(_data) && TMSAppointment::find(_data).ApptRefType == TMSApptRefType::Load)
                    {
                        fieldValues.insert(#CheckInOutId, _data);
                        fieldValues.insert(#LoadId, TMSAppointment::find(_data).ApptRefNum);
                    }
                    else
                    {
                        errorMessage = "@WAX1081";
                        hasError = true;
                        break;
                    }
                    
                    if (WHSLoadTable::exist(fieldValues.lookup(#LoadId)))
                    {
                        hasError = this.validateLoadIdCheckOut(fieldValues.lookup(#LoadId));
                    }
                    else
                    {
                        errorMessage = "@WAX3626";
                        hasError = true;
                    }
                }
                break;

Logger · 10.04.2017, 07:03

А как быстро исправить этот баг с учетом что приложение залочено?

Damn · 11.04.2017, 19:54

На подобные вопросы MS вроде обычно отвечает - "не делайте это". Ну то есть не используйте этот функционал.

trud · 12.04.2017, 04:47

Вот еще из новинок D365 - когда создаете индекс по умолчанию он теперь уникальный -Allow duplicates = No. А чтобы так сказать преждевременно не спугнуть разработчика, новый движок синхронизации в целях оптимизации вообще не пытается синхронизировать таблицу в окружении разработки если менялись только индексы.
Т.е. создаете индекс(не меняя никаких сво-в), тестируете, все ОК. далее заливаете на LCS, отдаете клиенту и вуаля - получаете ошибку синхронизации.
Создал по этому поводу реквест на ideas
https://ideas.dynamics.com/ideas/dyn...ions/ID0001383

mayk · 17.05.2017, 14:56

Вчера вылезло нечто странное в 2012 аксапте.

Код шёл примерно так (очень упрощенная версия)

X++:

[record1] = map.lookup(#current); 
tmpTable.value = strfmt("%1", record1.(fieldnum(RealTable, dataAreaid)))

И несмотря на то, что RealTable record1 был положен в карту абсолютно нормальным(dataAreaId заполнен, никаких select crosscompany, всё как обычно)
это вылетало с "Внутренняя ошибка номер 25".

Научный метод тыка показал, что info(record1.dataAreaId); работает и показывает код компании. А вот info(record1.(fieldnum(RealTable, dataAreaid))) вылетает.

Веселье продолжилось, дальнейшее шаманство показало что

X++:

[recordTmp] = map.lookup(#current); 
record1.data(recordTmp); // <<< копируем полученное из map'а
info(record1.(fieldnum(RealTable, dataAreaid)))
tmpTable.value = record1.(fieldnum(RealTable, dataAreaid))

работает.

Я ничего не понял.

**mazzy** · 17.05.2017, 15:10

Цитата:

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

Научный метод тыка показал, что info(record1.dataAreaId); работает и показывает код компании. А вот info(record1.(fieldnum(RealTable, dataAreaid))) вылетает.

Проверьте, не является ли map'ом ваш RealTable.
коды системных полей могут отличаться в map и в таблицах, которые реально находятся под мапом.

kashperuk · 17.05.2017, 15:50

Интересно если в первом случае сделать fieldNum(Common, DataAreaId)?

По-идее должны быть одинаковые идентификаторы системных полей, но вдруг

SRF · 17.05.2017, 16:42

Думаю это глюк с наследованием таблиц, вот пример накидал в джобике

X++:

static void InhTab(Args _args)
{
    AgreementHeader         ah;
    SalesAgreementHeader    sah;
    container               buf;
    Common                  record;
    
    select firstOnly sah;
    
    buf = [sah];
    
    [record] = buf;
    
    info(record.(fieldNum(Common, dataAreaId)));
}

Если запустить на выполнение то ошибка будет, а если поменять sah на ah, то все ок, скорее всего нужно делать для курсора явное приведение к базовому типу, тогда проблем не будет.
билд 6.3.3000.617

mnt_dx · 25.05.2017, 11:28

Нажмите на изображение для увеличения
Название: import.png
Просмотров: 310
Размер: 68.1 Кб
ID: 11426

trud · 06.07.2017, 05:57

инфолог тоже не пережил дигитал трансформашн

такой код в ах2012 и ниже выдавал 502 сообщения с ошибками и 502 инфо(что и ожидалось). при этом можно было скопировать содержимое одним кликом

X++:

int i;
for( i =1; i <= 502; i++) error(strFmt("line error %1", i));
for( i =1; i <= 502; i++) info(strFmt("line info %1", i));

в новой АХ(апдейт8) выдаются только 500 инфо, простой возможности копирования нет

kashperuk · 06.07.2017, 08:08

Цитата:

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

инфолог тоже не пережил дигитал трансформашн

такой код в ах2012 и ниже выдавал 502 сообщения с ошибками и 502 инфо(что и ожидалось). при этом можно было скопировать содержимое одним кликом

X++:

int i;
for( i =1; i <= 502; i++) error(strFmt("line error %1", i));
for( i =1; i <= 502; i++) info(strFmt("line info %1", i));

в новой АХ(апдейт8) выдаются только 500 инфо, простой возможности копирования нет

Да, с инфологом действительно все очень печально

Damn · 06.07.2017, 17:00

Цитата:

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

Да, с инфологом действительно все очень печально

Ну слава богу. А то мне уж начало казаться что мне одному мягко говоря неудобен новый инфолог.

trud · 19.07.2017, 05:06

Цитата:

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

Да, с инфологом действительно все очень печально

Зарегистрировал "идею", кому не лень проголосуйте
https://ideas.dynamics.com/ideas/dyn...ions/ID0002243
также чтобы добавили поддержку файлов в RunBase
https://ideas.dynamics.com/ideas/dyn...ions/ID0002242

Цитата:

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

Но опять же, не факт что команда MCR будет править код, ведь клиенты баги не репортят, а там мало ли что кому кажется.

Кстати удивительно точно подмечено, собственно на мой взгляд все текущие проблемы AX7 вызваны подобным подходом - изначально здравые идеи верхнего уровня(практически все "новинки" AX7 очень хороши) разбиваются о совершенно "формальную" реализацию с пропуском многих мелких деталей, что делает их во многом трудно используемым или вообще непригодным.
Интересно есть ли какие-нибудь методологии позволяющие как-то бороться с таким(типа если рабочий на конвейере увидел брак, то он должен остановить конвейер, а не просто забить, так как это не его дело).
Ведь не работают же так Apple и Google

kashperuk · 19.07.2017, 16:00

Цитата:

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

Ведь не работают же так Apple и Google

Еще как

kashperuk · 17.07.2017, 12:23

После изменения энума ModuleInventPurchSales чтоб он был Extensible, нашли такой код в классе MCRCatalogAreaAnalysisDP, так как стал валится Compiler Warning: ExtensibleEnumInNumericalAssignment

X++:

    AmountMST cost = this.itemPrice(ModuleInventPurchSales::Invent);
    AmountMST sales = this.itemPrice(ModuleInventPurchSales::Sales);
    ...

    //Avoid division by zero
    if (this.itemPrice(ModuleInventPurchSales::Sales == 0))
    {
        mcrCatalogAreaAnalysisTmp.CogsPercent = 0;
    }
    else
    {
        mcrCatalogAreaAnalysisTmp.CogsPercent = cost / Sales;
    }

А вот как наши доблестные девелоперы пофиксили это

Нажмите на изображение для увеличения
Название: ff.jpg
Просмотров: 424
Размер: 48.0 Кб
ID: 11566

Stitch_MS · 17.07.2017, 14:52

Цитата:

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

А вот как наши доблестные девелоперы пофиксили это

Выглядит так, будто доблестные девелоперы умеют писать скрипты, но не любят проверять результаты их работы.

kashperuk · 17.07.2017, 16:03

Цитата:

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

Выглядит так, будто доблестные девелоперы умеют писать скрипты, но не любят проверять результаты их работы.

Если бы дело было только в этом.
Это изменение отревьюило 2 человека.. То есть втроем, с учетом того что сам девелопер тоже правил, они не смогли нормально скобочки сосчитать, и их никак не удивила эта странная констркция со сравнением двух энумов..

skuull · 17.07.2017, 21:48

Цитата:

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

Если бы дело было только в этом.
Это изменение отревьюило 2 человека.. То есть втроем, с учетом того что сам девелопер тоже правил, они не смогли нормально скобочки сосчитать, и их никак не удивила эта странная констркция со сравнением двух энумов..

А сколько ещё изменений было в этом ревью ? Там же есть зависимость между длинной изменения и качеством его ревью