Перенос всех объектов с USR-слоя на VAR.

[oip]

Возник тут вот такой вопросик...

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

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

Спасибо!

[belugin]

Я делал наоборот c dis на usr, написал джоб который после переноса находит по имени таблицы и правит их мэпинг в SqlDictionary.

Но сами данные не правил. Наверное надо сначала выгрузить меппинг в какой-то файл, потом написать на транзакт SQL скрипт, который всё проапдейтит

[eugene egorov]

Переносили с USR на CUS с сохранением значений идентификаторов. Получились таблицы в CUS с номерами 50000 с хвостиком. Некрасиво но работает.

[oip]

Это плохо. Т.к. не накатишь никакой посторонний уср-слой, например. Может еще где грабли возникнут. Это ИМХО мина замедленного действия.

[eugene egorov]

Цитата:

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

Это плохо. Т.к. не накатишь никакой посторонний уср-слой, например. Может еще где грабли возникнут. Это ИМХО мина замедленного действия.

Про посторониие объекты - в любом слое эта проблема может возникнуть если пытаться импортить со значениями Id. Слияние приложений - вообще работа неблагодарная

[belugin]

Собственно джоб:

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]

Спасибо, Максим! Но это пока еще не решение всех проблем.

[belugin]

Это понятно. Я бы сначала епроанализировал, что, собственно, сломается, можно ли это как-то автоматически идентифицировать и проапдейтить. Например ссылки на классид, помечены ли ЕДТ

[oip]

Этим и занимаюсь сейчас. Тут надо понять, сколько вся эта процедура перехода времени займет и есть ли гарантия успеха...

[AndyD]

Максим, проще удалить данные из SQLDictionary и запустить через SQL Администрирование проверку таблиц

[belugin]

AndyD -- с этим были какие-то проблемы (кажется, он не понимал таблиц в имя которых на SQL стороне входит TableID - и вроде с индексами были проблемы)

[AndyD]

О, точно!
С длинными именами в любом случае будет проблема
С новым id у таблицы Axapta ее просто не увидит и создаст новую. Так что с ними в любом случае придется возиться (переливать данные)

[KiselevSA]

Цитата:

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

Этим и занимаюсь сейчас. Тут надо понять, сколько вся эта процедура перехода времени займет и есть ли гарантия успеха...

А если:
слить данные из всех таблиц, в которых были добавлены поля на usr-слое (включая и полностью созданные таблицы) в двоичном формате;
перенести модификации с usr на var;
выгрузить повторно с нового приложения в отдельную директорию;
заменить def файлы в старом на новые;
закачать данные.
Главная гадость - наличие полей RefRecId, ссылающихся на объекты в таблицах usr слоя

[oip]

На УСР слое есть более половины таблиц. Т.к. кое-кто включил у них у всех в свое время поля Modified и Created. Так что еще нужно будет проанализировать, единственное ли это изменение на уср-слое или нет. Проблема решаема, не спорю.

[glibs]

Просто переносили с USR на VAR. Экспортом-импортом проекта. Потом запускали синхронизацию из SQL-администрирования. С проблемами не сталкивались. Хотя база была тестовая. Возможно, самая каверзная таблица не попалась .

Идею, если не изменяет память, первый раз услыхал от EVGL.

[kashperuk]

жаль удалилось хорошее сообщение от sukhanchik.

[gl00mie]

Цитата:

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

жаль удалилось хорошее сообщение от sukhanchik.

У меня сохранился его текст, я написал автору, чтоб он создал сообщение еще раз.

[sukhanchik]

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

Собсно все.