update_recordset не работает с системными полями и таблицами?

[sukhanchik]

Zitat:

Zitat von ZVV

а если напрямую в БД, это был бы небольшой скриптик на несколько строчек... ))

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

Оформлено это просто в класс - чтобы можно было этот код убрать из ветки Jobs, как код, полезный при постепенном внедрении. Ну и конечно - добавлен интерфейс указания компаний для возможности использования консультантами этого джобика. Пункт меню сделан (в xpo я его не стал вкладывать)

[DSPIC]

А целостность данных?
Почему бы просто не сохранить данные в буфер, переключить компанию и вставить данные.
Примерно так:

static void copy2company(Args _args)
{
    InventTable     tmpInventTable, fromInventTable, toInventTable;
    ;

    tmpInventTable.setTmp();

    fromInventTable.skipDataMethods(true);
    while select fromInventTable
    {
        tmpInventTable.clear();
        buf2buf(fromInventTable, tmpInventTable);
        tmpInventTable.insert();
    }

    ttsbegin;
    changecompany ("DMO")
    {
        while select tmpInventTable
        {
            toInventTable.clear();
            buf2buf(tmpInventTable, toInventTable);

            if (toInventTable.validateWrite())
                toInventTable.insert();
        }
    }
    ttscommit;
}

[sukhanchik]

Zitat:

Zitat von DSPIC

А целостность данных?
Почему бы просто не сохранить данные в буфер, переключить компанию и вставить данные.

А потому что имеется такая ситуация. Была компания, в ней были данные. И вдруг, в какой-то момент - мы осознаем необходимость включения этой компании в виртуальную. changecompany в этом случае работать не будет - т.к. ДО внесения компании в виртуальную - мы просто не перейдем в виртуальную компанию. А после - мы уже не достанем наши старые данные (система будет искать записи с dataareaid равным виртуальной компании).
Переход в другую компанию, которая уже входит в виртуальную - это конечно вариант - но... ее может и не быть, например, мы решили объединить ряд компаний и создать новую виртуальную компанию.
Кстати, обращаю внимание, что нельзя перейти в саму виртуальную компанию. Можно только перейти в компанию, входящую в состав виртуальной.

На самом деле - мы отвлеклись от темы. Я привел пример - не для того, чтобы показать как это работает с виртуальными компаниями, а для того, чтобы показать, что прямое обращение к БД при замене dataAreaId если все делать по-честному - выливается не в одну строчку кода. И даже наоборот - мой вариант по сути применим только тогда, когда штатно (по аналогии как Вы показали) невозможно этого добиться. Хотя с т.з. функциональности оба примера работают одинаково - никакой целостности данных нигде не нарушается если нет связок по RecID (а если есть, то нарушается и там и там)

Кстати, Ваш код работать не будет. После changecompany временная таблица тоже ведь сменит компанию. Или я не понял хитрого хода конем?

[Alexx7]

Zitat:

Zitat von sukhanchik

.....
Кстати, Ваш код работать не будет. После changecompany временная таблица тоже ведь сменит компанию. Или я не понял хитрого хода конем?

Цель исключить общие таблицы из табличной колекции виртуальной компании и изменить компанию в исключенных таблицах.

Джоб действительно работать не захотел. Сделали напрямую через SQL. Задача решена.

Спасибо.

[sukhanchik]

Zitat:

Zitat von Alexx7

Цель исключить общие таблицы из табличной колекции виртуальной компании и изменить компанию в исключенных таблицах.

Во... именно для этих целей и предназначался мой джоб. Только в обратную сторону.
Так что если в будущем будет потребность повторить "на бис" процедуру - можно им будет воспользоваться

[Alexx7]

Zitat:

Zitat von sukhanchik

Во... именно для этих целей и предназначался мой джоб. Только в обратную сторону.
Так что если в будущем будет потребность повторить "на бис" процедуру - можно им будет воспользоваться

За джобик отдельное спасибо. (добавлю к репутации через 3 суток).

Через SQL, говорят, могут возникнуть трудности в дальнейшем.

[DSPIC]

Zitat:

Кстати, Ваш код работать не будет. После changecompany временная таблица тоже ведь сменит компанию. Или я не понял хитрого хода конем?

Я об этом думал, попробовал - работает. Т.е. данные из временной таблицы не пропадают при смене компании.

Zitat:

Джоб действительно работать не захотел.

Проверил ещё раз, ещё раз и ещё на работе, все работает. (dax40sp2)

[Alexx7]

Zitat:

Zitat von sukhanchik

Во... именно для этих целей и предназначался мой джоб. Только в обратную сторону.
Так что если в будущем будет потребность повторить "на бис" процедуру - можно им будет воспользоваться

Жесть! Поробовал на талице EmplTable. В параметрах задал "компания с данными" - vrt, а виртуальную компанию cmp. Ушел в ошибку. Вот стек:

Сообщение (14:06:50)
Сбой запроса на разрешение типа "SqlStatementExecutePermission".
(S)\Classes\SqlStatementExecutePermission\demand
(S)\Classes\Statement\executeQuery
(C)\Classes\ReplaceDataAreaId\updateTableRows - line 31
(C)\Classes\ReplaceDataAreaId\updateTables - line 28
(C)\Classes\ReplaceDataAreaId\run - line 19
(C)\Classes\ReplaceDataAreaId\main - line 7

Чего то скорее всего не хватает.

[sukhanchik]

Ну я ж сказал

Zitat:

Zitat von sukhanchik

В джобике отсутствует получение разрешений на исполнение кода. (Всякие там new *Permission().assert()).

Нужно до строчки, в которой возникает ошибка
(C)\Classes\ReplaceDataAreaId\updateTableRows - line 31

вставить new SqlStatementExecutePermission('sql-запрос').assert();

а после строчки - CodeAccessPermission::revertAssert();

Либо отключить параметр caslevel (установить его в значение disable) в конфигурации АОСа (это в реестре) и перезапустить АОС.

Лучше первый вариант - он правильнее.

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

Проверю -отпишусь

[sukhanchik]

Zitat:

Zitat von DSPIC

Я об этом думал, попробовал - работает. Т.е. данные из временной таблицы не пропадают при смене компании.

Проверил ещё раз, ещё раз и ещё на работе, все работает. (dax40sp2)

Прикольно... "Надо будет мужикам рассказать"

Поэкспериментирую.

[Bishop]

Zitat:

Zitat von sukhanchik

Нужно до строчки, в которой возникает ошибка
(C)\Classes\ReplaceDataAreaId\updateTableRows - line 31

вставить new SqlStatementExecutePermission('sql-запрос').assert();

Еще нужно учесть, что SqlStatementExecutePermission разрешен только на стороне сервера, поэтому нужно в классе изменить свойство RunOn = Server, либо добавить статический серверный конструктор...

[sukhanchik]

Обновил XPO. Теперь он с разрешениями. Да, и необходимо учесть замечание выше по поводу RunOn=Server и сделать соответствующий пункт меню с RunOn=Server

[SRF]

Zitat:

Zitat von lev

на таблицах есть метод overwriteSystemfields()... если хотите изменять системные поля, перед апдейтом нужно вызывать этот метод с параметром true (overwriteSystemfields(true))...

Добрый день.

На самом деле метод overwriteSystemfields() предназначен для другого - изменить значения системных полей у вновь создаваемых записей.
Ниже пример, таблица Test - имеет одно текстовое поле ItemId.

static void SRF_Test(Args _args)
{
    Test    test;
    ;
    test.ItemId = 'dmo';
    test.overwriteSystemfields(true);
    test.(fieldNum(Test, DataAreaId)) = 'dmo';
    test.insert();
}

Для уже существующих записей, изменить системные поля штатными средствами AX нельзя, и метод overwriteSystemfields() тут не поможет.

[sukhanchik]

Zitat:

Zitat von SRF

На самом деле метод overwriteSystemfields() предназначен для другого - изменить значения системных полей у вновь создаваемых записей.

А с чего Вы взяли?

Zitat:

Zitat von SRF

Для уже существующих записей, изменить системные поля штатными средствами AX нельзя, и метод overwriteSystemfields() тут не поможет.

Вот это неправда. На поля modified* вполне можно таким образом воздействовать. Они не изменятся при вызове update если вызвать overwriteSystemFields(true).

Более того - их можно изменить

static void Job(Args _args)
{
    VendTable vendTable;
    ;
    ttsbegin;
    select forupdate vendTable;
    info(strfmt("%1 %2", vendTable.AccountNum, vendTable.modifiedBy));
    vendTable.overwriteSystemfields(true);
    vendTable.(fieldnum(VendTable, modifiedBy)) = 'zzzz';
    vendTable.doUpdate();
    ttscommit;
    info(strfmt("%1 %2", vendTable.AccountNum, vendTable.modifiedBy));
}

При этом пользователя zzzz может не существовать в базе

DAX 4.0 SP2

[Alexx7]

sukhanchik,
Колупаю Ваш обновленный джоб. Уходит в ошибку в строрчке:

rst  = stmt.executeQuery(sSQL);

Вот стек:
[s]\Classes\Statement\executeQuery (0)
[c]\Classes\ReplaceDataAreaId\updateTableRows (39)
[c]\Classes\ReplaceDataAreaId\updateTables (28)
[c]\Classes\ReplaceDataAreaId\run (19)
[c]\Classes\ReplaceDataAreaId\main (7)

Что ещё можно посмотреть, чтобы он отработал.
Спасибо.

[SRF]

Zitat:

Zitat von sukhanchik

А с чего Вы взяли?


Вот это неправда. На поля modified* вполне можно таким образом воздействовать. Они не изменятся при вызове update если вызвать overwriteSystemFields(true).

Более того - их можно изменить

static void Job(Args _args)
{
    VendTable vendTable;
    ;
    ttsbegin;
    select forupdate vendTable;
    info(strfmt("%1 %2", vendTable.AccountNum, vendTable.modifiedBy));
    vendTable.overwriteSystemfields(true);
    vendTable.(fieldnum(VendTable, modifiedBy)) = 'zzzz';
    vendTable.doUpdate();
    ttscommit;
    info(strfmt("%1 %2", vendTable.AccountNum, vendTable.modifiedBy));
}

Anhang 5267

При этом пользователя zzzz может не существовать в базе

DAX 4.0 SP2

Взял с того, как используется этот метод в стандартной аксапте.

У меня на DAX 4.0 TAP 3(виртуалка по 4-ке от МС) Ваш job не изменил значение поля modifiedBy.

То, что выводится в инфолог, еще не значит, что значения изменились в таблице.
Поставьте перед вторым info или посмотрите значение в базе

vendTable.reread();

[sukhanchik]

Zitat:

Zitat von SRF

То, что выводится в инфолог, еще не значит, что значения изменились в таблице.

Ваша правда. Я забыл, что для этого требуется изменения хотя бы одного поля.

static void Job(Args _args)
{
    VendTable vendTable;
    ;
    ttsbegin;
    select forupdate vendTable;
    info(strfmt("%1 %2", vendTable.AccountNum, vendTable.modifiedBy));
    ttscommit;
    return;
    vendTable.overwriteSystemfields(true);
    vendTable.Address += ' ';
    vendTable.(fieldnum(VendTable, modifiedBy)) = 'zzzz';
    vendTable.doUpdate();
    ttscommit;
    info(strfmt("%1 %2", vendTable.AccountNum, vendTable.modifiedBy));
    vendTable.reread();
    info(strfmt("%1 %2", vendTable.AccountNum, vendTable.modifiedBy));
}

Вот так работает. Попробуйте - и у Вас тоже все изменится. Это и на 3.0 работало.

[sukhanchik]

Zitat:

Zitat von Alexx7

sukhanchik,
Колупаю Ваш обновленный джоб. Уходит в ошибку в строрчке:

rst  = stmt.executeQuery(sSQL);

Вот стек:
[s]\Classes\Statement\executeQuery (0)
[c]\Classes\ReplaceDataAreaId\updateTableRows (39)
[c]\Classes\ReplaceDataAreaId\updateTables (28)
[c]\Classes\ReplaceDataAreaId\run (19)
[c]\Classes\ReplaceDataAreaId\main (7)

Что ещё можно посмотреть, чтобы он отработал.
Спасибо.

А что за ошибка? А то ж нельзя лечить не зная диагноза

[Alexx7]

Zitat:

Zitat von sukhanchik

А что за ошибка? А то ж нельзя лечить не зная диагноза

Извиняюсь:

Сообщение (15:43:40) Сбой запроса на разрешение типа "SqlStatementExecutePermission".
(S)\Classes\SqlStatementExecutePermission\demand
(S)\Classes\Statement\executeQuery
(C)\Classes\ReplaceDataAreaId\updateTableRows - line 39
(C)\Classes\ReplaceDataAreaId\updateTables - line 28
(C)\Classes\ReplaceDataAreaId\run - line 19
(C)\Classes\ReplaceDataAreaId\main - line 7

[sukhanchik]

Хм.. у меня не выругался. Сделал на всякий случай отдельную переменную Statement в методе updateTableRows на каждый вызов. XPO обновил - попробуйте.
Обратите внимание - все ли вызовы executeQuery обрамлены в new SqlStatementExecutePermission(sSQL).assert() и CodeAccessPermission::revertAssert() ?
Тот ли запрос sSQL передается в SqlStatementExecutePermission, что и в executeQuery ?