|
![]() |
#1 |
Axapta
|
Перенос всех объектов с USR-слоя на VAR.
Возник тут вот такой вопросик...
Есть приложение, в котором что-то разработано на USR-слое. И не так уж и мало. Встала задача перенести все это на слой ниже (скажем, на VAR - сейчас он пустой) - не спрашивайте почему, это большая политика. При том, на уже работающей аксапте с БД на примерно 5 Гб. Все соответствующие темы на форуме прочитил, так что в поиск не отправляйте.... Много думал.... Извините, что не стану все прочитанное резюмировать сейчас - небольшой цейтнот, поэтому просто спрошу кого-либо, у кого был такой опыт. Больше всего напрягают, например, места в аксапте, где идет связь по TableId, например (а кое-где даже айди классов вроде как сохраняются). Если айдишники объектов не сохранять - придется ручками все такие места править. А сохранить - тоже неправильно. Так же боюсь за сохранность данных, т.к. первые эксперимент закончился неудачно - данные в таблице почему-то пропали. Но тщательно я еще не эксперементировал со всем этим, сейчас только начну. В общем кто может - поделитесь, пожалуйста, своими мыслями и опытом. Обещаю потом все резюмировать. Но пока мне кажется, что задача за короткий промежуток времени не выполнима. Спасибо!
__________________
С уважением, Олег. |
|
![]() |
#2 |
Участник
|
Я делал наоборот c dis на usr, написал джоб который после переноса находит по имени таблицы и правит их мэпинг в SqlDictionary.
Но сами данные не правил. Наверное надо сначала выгрузить меппинг в какой-то файл, потом написать на транзакт SQL скрипт, который всё проапдейтит |
|
![]() |
#3 |
Участник
|
Переносили с USR на CUS с сохранением значений идентификаторов. Получились таблицы в CUS с номерами 50000 с хвостиком. Некрасиво но работает.
![]()
__________________
любитель портвейна и снов с прокисшей капустой в усах |
|
![]() |
#4 |
Axapta
|
Это плохо. Т.к. не накатишь никакой посторонний уср-слой, например. Может еще где грабли возникнут. Это ИМХО мина замедленного действия.
__________________
С уважением, Олег. |
|
![]() |
#5 |
Участник
|
Цитата:
![]()
__________________
любитель портвейна и снов с прокисшей капустой в усах |
|
![]() |
#6 |
Участник
|
Собственно джоб:
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). |
![]() |
#7 |
Axapta
|
Спасибо, Максим! Но это пока еще не решение всех проблем.
![]()
__________________
С уважением, Олег. |
|
![]() |
#8 |
Участник
|
Это понятно. Я бы сначала епроанализировал, что, собственно, сломается, можно ли это как-то автоматически идентифицировать и проапдейтить. Например ссылки на классид, помечены ли ЕДТ
|
|
![]() |
#9 |
Axapta
|
Этим и занимаюсь сейчас. Тут надо понять, сколько вся эта процедура перехода времени займет и есть ли гарантия успеха...
__________________
С уважением, Олег. |
|
![]() |
#10 |
Злыдни
|
Цитата:
слить данные из всех таблиц, в которых были добавлены поля на usr-слое (включая и полностью созданные таблицы) в двоичном формате; перенести модификации с usr на var; выгрузить повторно с нового приложения в отдельную директорию; заменить def файлы в старом на новые; закачать данные. Главная гадость - наличие полей RefRecId, ссылающихся на объекты в таблицах usr слоя ![]()
__________________
люди...считают, что если техника не ломается, то ее не нужно ремонтировать. Инженеры считают, что если она не ломается, то нуждается в совершенствовании. |
|
![]() |
#11 |
Участник
|
Максим, проще удалить данные из SQLDictionary и запустить через SQL Администрирование проверку таблиц
__________________
Axapta v.3.0 sp5 kr2 |
|
![]() |
#12 |
Участник
|
AndyD -- с этим были какие-то проблемы (кажется, он не понимал таблиц в имя которых на SQL стороне входит TableID - и вроде с индексами были проблемы)
|
|
![]() |
#13 |
Участник
|
О, точно!
С длинными именами в любом случае будет проблема ![]() С новым id у таблицы Axapta ее просто не увидит и создаст новую. Так что с ними в любом случае придется возиться (переливать данные)
__________________
Axapta v.3.0 sp5 kr2 |
|
![]() |
#14 |
Axapta
|
На УСР слое есть более половины таблиц. Т.к. кое-кто включил у них у всех в свое время поля Modified и Created. Так что еще нужно будет проанализировать, единственное ли это изменение на уср-слое или нет. Проблема решаема, не спорю.
__________________
С уважением, Олег. |
|
![]() |
#15 |
Member
|
Просто переносили с USR на VAR. Экспортом-импортом проекта. Потом запускали синхронизацию из SQL-администрирования. С проблемами не сталкивались. Хотя база была тестовая. Возможно, самая каверзная таблица не попалась
![]() Идею, если не изменяет память, первый раз услыхал от EVGL.
__________________
С уважением, glibs® |
|
![]() |
#16 |
Участник
|
жаль удалилось хорошее сообщение от sukhanchik.
|
|
![]() |
#17 |
Участник
|
|
|
|
За это сообщение автора поблагодарили: sukhanchik (5). |
![]() |
#18 |
Administrator
|
Спасибо 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, полезное, слой приложения |
|
|