AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 07.06.2007, 11:37   #1  
oip is offline
oip
Axapta
Лучший по профессии 2014
 
2,564 / 1416 (53) ++++++++
Регистрация: 28.11.2005
Записей в блоге: 1
Перенос всех объектов с USR-слоя на VAR.
Возник тут вот такой вопросик...

Есть приложение, в котором что-то разработано на USR-слое. И не так уж и мало. Встала задача перенести все это на слой ниже (скажем, на VAR - сейчас он пустой) - не спрашивайте почему, это большая политика. При том, на уже работающей аксапте с БД на примерно 5 Гб. Все соответствующие темы на форуме прочитил, так что в поиск не отправляйте.... Много думал.... Извините, что не стану все прочитанное резюмировать сейчас - небольшой цейтнот, поэтому просто спрошу кого-либо, у кого был такой опыт. Больше всего напрягают, например, места в аксапте, где идет связь по TableId, например (а кое-где даже айди классов вроде как сохраняются). Если айдишники объектов не сохранять - придется ручками все такие места править. А сохранить - тоже неправильно. Так же боюсь за сохранность данных, т.к. первые эксперимент закончился неудачно - данные в таблице почему-то пропали. Но тщательно я еще не эксперементировал со всем этим, сейчас только начну.

В общем кто может - поделитесь, пожалуйста, своими мыслями и опытом. Обещаю потом все резюмировать. Но пока мне кажется, что задача за короткий промежуток времени не выполнима.

Спасибо!
Старый 07.06.2007, 11:54   #2  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2925 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Я делал наоборот c dis на usr, написал джоб который после переноса находит по имени таблицы и правит их мэпинг в SqlDictionary.

Но сами данные не правил. Наверное надо сначала выгрузить меппинг в какой-то файл, потом написать на транзакт SQL скрипт, который всё проапдейтит
Старый 07.06.2007, 11:56   #3  
eugene egorov is offline
eugene egorov
Участник
Аватар для eugene egorov
 
273 / 97 (4) ++++
Регистрация: 05.06.2002
Адрес: Москва
Переносили с USR на CUS с сохранением значений идентификаторов. Получились таблицы в CUS с номерами 50000 с хвостиком. Некрасиво но работает.
__________________
любитель портвейна и снов с прокисшей капустой в усах
Старый 07.06.2007, 11:57   #4  
oip is offline
oip
Axapta
Лучший по профессии 2014
 
2,564 / 1416 (53) ++++++++
Регистрация: 28.11.2005
Записей в блоге: 1
Это плохо. Т.к. не накатишь никакой посторонний уср-слой, например. Может еще где грабли возникнут. Это ИМХО мина замедленного действия.
Старый 07.06.2007, 12:07   #5  
eugene egorov is offline
eugene egorov
Участник
Аватар для eugene egorov
 
273 / 97 (4) ++++
Регистрация: 05.06.2002
Адрес: Москва
Цитата:
Сообщение от oip Посмотреть сообщение
Это плохо. Т.к. не накатишь никакой посторонний уср-слой, например. Может еще где грабли возникнут. Это ИМХО мина замедленного действия.
Про посторониие объекты - в любом слое эта проблема может возникнуть если пытаться импортить со значениями Id. Слияние приложений - вообще работа неблагодарная
__________________
любитель портвейна и снов с прокисшей капустой в усах
Старый 07.06.2007, 12:15   #6  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2925 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Собственно джоб:
X++:
static void Correct_SQL_Dictionary(Args _args)
{
    SQLDictionary d;
    SQLDictionary tmp;
    str tableName;
;
    tmp.setTmp();
    ttsBegin;
    while select d
        where
            (
                d.tabId>=30001
                &&
                d.tabId<=60000
            )
            ||
            (
                d.fieldId>=30001
                &&
                d.fieldId<=60000
            )
    {
        tmp.data(d);
        tmp.insert();
    }

    DELETE_FROM  d
        where
            (
                d.tabId>=30001
                &&
                d.tabId<=60000
            )
            ||
            (
                d.fieldId>=30001
                &&
                d.fieldId<=60000
            )
    ;

    while select tmp order by tabid, fieldID
    {
        d.data(tmp);
        if (!(
            tmp.tabId>=30001
            &&
            tmp.tabId<=60000
        ))
            tableName = '';
        if (!tmp.fieldId)
            tableName = tmp.name;
        if (tableName)
            d.TabId = tableName2ID(tableName);
        if (tmp.fieldId)
            d.fieldId = fieldName2ID(d.TabId, tmp.name);
        if (d.tabId && (!tmp.fieldId || d.fieldId))
            d.insert();
    }
    ttsCommit;
    info('ok');
}
За это сообщение автора поблагодарили: oip (10).
Старый 07.06.2007, 12:17   #7  
oip is offline
oip
Axapta
Лучший по профессии 2014
 
2,564 / 1416 (53) ++++++++
Регистрация: 28.11.2005
Записей в блоге: 1
Спасибо, Максим! Но это пока еще не решение всех проблем.
Старый 07.06.2007, 12:22   #8  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2925 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Это понятно. Я бы сначала епроанализировал, что, собственно, сломается, можно ли это как-то автоматически идентифицировать и проапдейтить. Например ссылки на классид, помечены ли ЕДТ
Старый 07.06.2007, 12:24   #9  
oip is offline
oip
Axapta
Лучший по профессии 2014
 
2,564 / 1416 (53) ++++++++
Регистрация: 28.11.2005
Записей в блоге: 1
Этим и занимаюсь сейчас. Тут надо понять, сколько вся эта процедура перехода времени займет и есть ли гарантия успеха...
Старый 07.06.2007, 12:29   #10  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2479 (88) +++++++++
Регистрация: 20.08.2005
Максим, проще удалить данные из SQLDictionary и запустить через SQL Администрирование проверку таблиц
__________________
Axapta v.3.0 sp5 kr2
Старый 07.06.2007, 12:34   #11  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2925 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
AndyD -- с этим были какие-то проблемы (кажется, он не понимал таблиц в имя которых на SQL стороне входит TableID - и вроде с индексами были проблемы)
Старый 07.06.2007, 12:41   #12  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2479 (88) +++++++++
Регистрация: 20.08.2005
О, точно!
С длинными именами в любом случае будет проблема
С новым id у таблицы Axapta ее просто не увидит и создаст новую. Так что с ними в любом случае придется возиться (переливать данные)
__________________
Axapta v.3.0 sp5 kr2
Старый 07.06.2007, 13:55   #13  
KiselevSA is offline
KiselevSA
Злыдни
Аватар для KiselevSA
Злыдни
Лучший по профессии 2015
 
958 / 333 (13) ++++++
Регистрация: 25.01.2002
Адрес: Москва
Цитата:
Сообщение от oip Посмотреть сообщение
Этим и занимаюсь сейчас. Тут надо понять, сколько вся эта процедура перехода времени займет и есть ли гарантия успеха...
А если:
слить данные из всех таблиц, в которых были добавлены поля на usr-слое (включая и полностью созданные таблицы) в двоичном формате;
перенести модификации с usr на var;
выгрузить повторно с нового приложения в отдельную директорию;
заменить def файлы в старом на новые;
закачать данные.
Главная гадость - наличие полей RefRecId, ссылающихся на объекты в таблицах usr слоя
__________________
люди...считают, что если техника не ломается, то ее не нужно ремонтировать. Инженеры считают, что если она не ломается, то нуждается в совершенствовании.
Старый 07.06.2007, 13:58   #14  
oip is offline
oip
Axapta
Лучший по профессии 2014
 
2,564 / 1416 (53) ++++++++
Регистрация: 28.11.2005
Записей в блоге: 1
На УСР слое есть более половины таблиц. Т.к. кое-кто включил у них у всех в свое время поля Modified и Created. Так что еще нужно будет проанализировать, единственное ли это изменение на уср-слое или нет. Проблема решаема, не спорю.
Старый 07.06.2007, 22:23   #15  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 911 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
Просто переносили с USR на VAR. Экспортом-импортом проекта. Потом запускали синхронизацию из SQL-администрирования. С проблемами не сталкивались. Хотя база была тестовая. Возможно, самая каверзная таблица не попалась .

Идею, если не изменяет память, первый раз услыхал от EVGL.
__________________
С уважением,
glibs®
Старый 09.06.2007, 10:50   #16  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
жаль удалилось хорошее сообщение от sukhanchik.
Старый 09.06.2007, 11:26   #17  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5798 (201) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от kashperuk Посмотреть сообщение
жаль удалилось хорошее сообщение от sukhanchik.
У меня сохранился его текст, я написал автору, чтоб он создал сообщение еще раз.
За это сообщение автора поблагодарили: sukhanchik (5).
Старый 09.06.2007, 11:56   #18  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,314 / 3547 (125) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Спасибо gl00mie за сохраненный текст. Второй раз его написать было бы тяжелее
Привожу его:

На самом деле - не вижу больших проблем по опусканию в VAR - эта процедура вообще может выполняться на периодической основе. Учитывая, что стандартный функционал не тронут (USR-слой) - то сложности могут возникнуть только с данными своего функционала.
Потенциальные сложности переноса данных:
1. Хранение в таблицах идентификаторов объектов (как было написано - tableId, ClassId и проч).
2. Наличие в функционале таблиц с именами более 30 символов (которые в БД заканчиваются ID-шниками)

Плюс - потенциальная проблема - некорректного импорта XPO (слетание дисплей методов в группах полей и т.д.)

По порядку:
1.
а) Вы уверены, что в вашем функционале ТОЧНО существуют таблицы, в которых хранятся именно ID классов (причем ваших же классов) ?
б) Тот же вопрос, но по отношению к TableID и прочим объектам в АОТ
Допустим, ответ ДА. Хотя в будущем я бы не рекомендовал так делать. В любом случае вы должны знать ВСЕ места, где есть такое.
Тогда идем в Аксапту в ее табличку UtilIDElements (которая хранится в AOD-шнике, а не в базе). Среди прочих данных в ней существуют поля ID элемента и его название. Создаем новую таблицу (с названием до 30 символов, чтобы потом не мучаться) и пишем джобик, который в эту таблицу переливает данные из диапазона с ID 50000-59999 (нам же только USR-слой нужен). Т.о. мы получаем свою таблицу - с ID и названием объекта

2. В другой своей таблице также джобиком сохраняем аналогичную "выжимку" из таблицы SQLDictionary (фильтруя по tabId из диапазона 50000-59999, а также по различиям в названиях в АОТе и в БД - это поля name и sqlname). В этой таблице есть соответствие АОТ-вских названий таблиц и полей - БД-шным.

3. Опускаем USR в VAR, т.е. экспортим USR, убиваем файлы axusr.*, заходим в VAR и импортим XPO (не забываем, что импортить XPO надо дважды - чтобы гарантированно ничего не слетело). XPO импортируется без сохранения ID. Все компилим (как минимум - VAR-слой) и синхронизим Пункт 3 весь делается на отдельной на базе-пустышке.

4. Натравливаем получившееся приложение на БД, в которой мы делали первых 2 пункта. НЕ СИНХРОНИЗИРУЕМ!!! Трем всю таблицу SQLDictionary и запускаем проверку таблиц через Администрирование\Периодические операции \SQL Администрирование\Проверка таблиц. SQLDictionary переформируется под новые реалии. Синхронизацию НЕ ЗАПУСКАЕМ!

5. Вспоминаем, что у нас есть таблица из п.2, в которой есть соответствие старым названиям в БД и АОТу. Залезаем в БД - пишем скрипт, в котором джойним данные из таблицы п.2 и новой SQLDictionary.
В цикле выборки из этого джойна пишем что-то типа ALTER TABLE бла бла бла - в общем команду, которая переименовывает поля и таблицы в БД.
У таблиц поле fieldId в нашей табл из п.2 равно нулю - соотв это одна команда, для полей - другая.
Сразу оговорюсь - все это испытано на SQL Server - если у вас Oracle - то синтаксис команд нужно уточнить для Oracle (мало ли там какие заморочки). После всей процедуры для верности следует сделать синхронизацию.

5. В таблицу из п.1 джобиком из нового приложения Аксапты переливаем новые ID-шники элементов АОТ, ориентируясь на имена уже сохраненных элементов.

6. Самый сложный пункт. Здесь потребуется пройтись по всем местам, где у вас хранятся ID элементов АОТ в таблицах и их перебить на новые, пользуясь данными таблицы из пп.1 и 5.
Мораль - не храните ID-шники АОТа в БД - чтобы потом не было мучительно больно.

Собсно все.
__________________
Возможно сделать все. Вопрос времени
За это сообщение автора поблагодарили: SerAl (1), oip (10), gl00mie (6).
Теги
faq, fieldid, id объекта, sqldictionary, tableid, полезное, слой приложения

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Не сохраняются изменения при переносе с CUS слоя на USR maximka DAX: Администрирование 2 18.01.2007 13:05
var против usr данных Aslan DAX: Программирование 4 26.01.2006 14:05
Удаление таблицы из USR слоя mlapa DAX: Администрирование 12 22.04.2005 11:13
Перенос разработок с USR на VAR Paul_ST DAX: Программирование 8 01.11.2004 18:06
как перемещать таблицы, формы со слоя USR на слой VAR ? ddadream DAX: Функционал 6 10.06.2003 13:54

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 17:40.