Спасибо 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-шники АОТа в БД - чтобы потом не было мучительно больно.
Собсно все.