update_recordset не работает с системными полями и таблицами? - Страница 2 - DAX: Программирование

**sukhanchik** · 14.10.2009, 23:33

Цитата:

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

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

))

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

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

DSPIC · 14.10.2009, 23:46

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

X++:

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** · 15.10.2009, 00:26

Цитата:

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

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

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

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

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

Alexx7 · 15.10.2009, 06:48

Цитата:

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

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

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

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

Спасибо.

**sukhanchik** · 15.10.2009, 09:10

Цитата:

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

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

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

Alexx7 · 15.10.2009, 10:19

Цитата:

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

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

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

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

DSPIC · 15.10.2009, 11:18

Цитата:

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

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

Цитата:

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

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

Alexx7 · 15.10.2009, 12:07

Цитата:

Сообщение от 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** · 15.10.2009, 13:07

Ну я ж сказал

Цитата:

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

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

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

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

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

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

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

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

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

**sukhanchik** · 15.10.2009, 13:09

Цитата:

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

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

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

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

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

Bishop · 15.10.2009, 14:58

Цитата:

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

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

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

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

**sukhanchik** · 16.10.2009, 00:18

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

SRF · 16.10.2009, 06:37

Цитата:

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

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

Добрый день.

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

X++:

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

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

**sukhanchik** · 16.10.2009, 09:29

Цитата:

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

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

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

Цитата:

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

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

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

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

X++:

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));
}

Нажмите на изображение для увеличения
Название: job.PNG
Просмотров: 314
Размер: 23.5 Кб
ID: 5267

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

DAX 4.0 SP2

Alexx7 · 16.10.2009, 09:48

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

X++:

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 · 16.10.2009, 09:57

Цитата:

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

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

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

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

X++:

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));
}

Вложение 5267

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

DAX 4.0 SP2

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

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

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

.
Поставьте перед вторым info или посмотрите значение в базе

X++:

vendTable.reread();

**sukhanchik** · 16.10.2009, 10:34

Цитата:

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

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

.

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

X++:

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** · 16.10.2009, 11:56

Цитата:

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

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

X++:

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 · 16.10.2009, 13:44

Цитата:

Сообщение от 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** · 16.10.2009, 17:02

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

Похожие темы
Тема	Автор	Раздел	Ответов	Посл. сообщение
непонятности с полями modifiedTime, modifiedDate др.	PavelSR	DAX: Программирование	4	17.03.2007 10:28
Фильтр в форме по Looup с двумя таблицами	LexusS	DAX: Программирование	3	21.07.2006 10:42
JOIN программно на форме не работает	rohlenko	DAX: Программирование	2	31.03.2005 15:41
CRM ABC, SWOT анализ Как это работает и работает ли вообще.	ShadowFromXZone	DAX: Функционал	16	02.03.2004 18:09
связь между таблицами	Valia	DAX: Программирование	2	09.10.2003 18:36

Опции темы	Поиск в этой теме
Версия для печати Отправить по электронной почте	Поиск в этой теме: Расширенный поиск
Опции просмотра
Линейный вид Комбинированный вид Древовидный вид