dataareaid conpeek

[Logger]

Возможно уже было, но на форуме не нашел.
Наткнулся на странный глюк, если передавать common как элемент контейнера, то при "доставании" из контейнера может слететь dataareaid

static void JobCheckSerialize2(Args _args)
{
    CompanyId   CompanyIdFrom = "300";
    CompanyId   CompanyIdTo   = "dat";
    salesLine   salesLineFrom;
    salesLine   salesLineTo;
    salesLine   salesLineTo2;
    container   con;
    anyType     a;
    ;
    changeCompany(CompanyIdFrom)
    {
        salesLineFrom = null;
        select salesLineFrom;
        info(strFMT("Сначала %1; %2", salesLineFrom.dataAreaId, salesLineFrom.RecId));
        con = [salesLineFrom];
        int2str(salesLineTo2.RecId);
    }
    changeCompany(CompanyIdTo)
    {
        salesLineTo = null;
        //a = conPeek(con,1);
        //salesLineTo2.data(conPeek(con,1));
        salesLineTo  = conPeek(con,1);
        if(salesLineTo.dataAreaId == salesLineFrom.dataAreaId)
            info(strFMT("Потом %1; %2; Все в порядке, значения dataareaId сопадают", salesLineTo.dataAreaId, salesLineTo.RecId));
        else
            error(strFMT("Потом %1; %2; Ошибка, значения dataareaId не сопадают", salesLineTo.dataAreaId, salesLineTo.RecId));
    }
}

Ax 3.0 KR3

[sukhanchik]

Поскольку контейнер - это суть строковый тип (и относится к простым скалярным типам, т.е. не содержащим объект) - то помещение записи в контейнер - суть есть копирование значений всех полей в этот контейнер.

Распаковка происходит аналогично. А какие поля нельзя поменять из кода? Системные. Но тут видимо отрабатывает overwritesystemfields(true) (поле createdBy сохраняется).
RecId тоже можно поменять, но при вставке записи система все равно свой запишет.
А вот dataareaid - фиг. Это, пожалуй единственное поле, которое "незыблемо".

Поэтому сию особенность имеет смысл помнить - но она вполне на мой взгляд объяснима.

Повторял на AX4 SP2

[Logger]

Это понятно.
Но как-то неожиданно.

Кстати, вызов common.data() не в исходной компании тоже изменил dataareaId.
Т.е. дубликата не получается.

[sukhanchik]

У метода data есть некоторые особенности - я о них писал

[ZVV]

Цитата:

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

Кстати, вызов common.data() не в исходной компании тоже изменил dataareaId.
Т.е. дубликата не получается.

Вы неверно трактуете точку изменения поля dataareaid.

Оно происходит не при распаковке (извлечения) данных из контейнера, а при смене компании!

changeCompany(CompanyIdTo)

Проверьте в дебагере, при выполненни этого кода (т.е. при входе в блок с другой компанией) поле dataareaid именно в контейнере(!) меняется на новое, и возвращается на на старое, при выходе из этого блока.

Так что data() тут уже не при чём... Всё дело в контейнере...
Видимо фича такая... для удобства

[Logger]

Цитата:

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

Вы неверно трактуете точку изменения поля dataareaid.

Оно происходит не при распаковке (извлечения) данных из контейнера, а при смене компании!

Не. Сомнительно что при смене компании ядро перебивает во всех контейнерах поля dataareaId - там же данные в бинарном виде лежат - их распаковывать надо.

Скорее всего это багофича работы конструктора объекта common - при создании экземпляра в dataareaId класть текущую компанию. Соответственно это проявляется при conpeek, присваиваниях вида [common] = con, и при работе отладчика тоже, так как чтобы представить нам содержимое контейнера, ядро вынуждено где-то внутри себя сделать операцию аналогичную conpeek - создать экземпляр объекта common.