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

lev · 14.10.2009, 17:28

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

вообще, если уж надо просто изменить у записей в таблице компанию, то лучше это сделать напрямую через SQL\ORACLE (может это и некрасиво, но работает 100%

)

P.S. Замечания к джобу остаются в силе.

**sukhanchik** · 14.10.2009, 21:41

Такая бурная дискуссия

. На самом деле невозможно штатными средствами Аксапты изменить поле Dataareaid. Более того - это некорректно. У вас, к примеру, могут RecId быть в одной таблице в разных компаниях одинаковые...

Такая задача (по перебивке dataareaid) имеет смысл - если нужно включить (выключить) какую-то компанию в виртуальную. В этом случае в ряде таблиц нужно (и можно) заменить поле dataareaid. Этот случай решается (достаточно несложно) через SQL-оператор.

**sukhanchik** · 14.10.2009, 22:58

Нашел в своих загашниках "джобик" Class_ReplaceDataAreaId.xpo (оформленный как класс-наследник RunBase) по перебивке dataAreaId. Запрашиваются следующие параметры:
Компания с данными - невиртуальная компания с данными. Это компания ИЗ
Виртуальная компания - виртуальная компания с данными. Это компания В
Имя таблицы - имя таблицы в АОТ, в которой перебиваются данные.
Точное соответствие - Да, если указывается точное имя таблицы. Нет, если в поле Имя таблицы будет указано к примеру Invent* - т.е. обработать все таблицы, начинающиеся на Invent

Джобик грамотно перебивает поле dataareaid и также перебивает поле RecID (поэтому обработка построчная). Для изменения записей используются команды вне AX. Есть отдельная врезка кода для Oracle и для SQL Server, т.е. джобик, несмотря на то, что обращения идут к БД - поддерживает обе платформы.

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

Джобик писался изначально для 3.0 и был успешно оттестирован на:
3.0 SP3 CU1 + SQL Server 2000
3.0 SP3 CU1 + Oracle 10i
4.0 SP2 + Oracle 10i

Предполагаю, что на SQL Server 2005 он также будет работать

Обновлено: В файл добавлена корректная обработка разрешений

ZVV · 14.10.2009, 23:11

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

))

**sukhanchik** · 14.10.2009, 23:33

Цитата:

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

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

))

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

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

**sukhanchik** · 15.10.2009, 13:07

Ну я ж сказал

Цитата:

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

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

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

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

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

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

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

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

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

Bishop · 15.10.2009, 14:58

Цитата:

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

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

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

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

Bishop · 16.10.2009, 19:12

Цитата:

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

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

Повторюсь...
Судя по строке "(C)\Classes\ReplaceDataAreaId\updateTableRows ", ваш класс работает на клиенте.

Дело в том, что statement - это серверный класс, и выполняется он всегда на сервере, а permission вы даете на стороне клиента...

**sukhanchik** · 16.10.2009, 23:20

Цитата:

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

Повторюсь...
Судя по строке "(C)\Classes\ReplaceDataAreaId\updateTableRows ", ваш класс работает на клиенте.

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

. Иначе есть шанс его потерять.

Цитата:

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

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

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, говорят, могут возникнуть трудности в дальнейшем.

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

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

DSPIC · 15.10.2009, 11:18

Цитата:

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

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

Цитата:

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

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

**sukhanchik** · 15.10.2009, 13:09

Цитата:

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

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

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

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

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

**sukhanchik** · 16.10.2009, 00:18

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

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)

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

**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)

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

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

Похожие темы
Тема	Автор	Раздел	Ответов	Посл. сообщение
непонятности с полями 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

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