Синхронизация апликейшенов.

[NJD]

Ситуация такая - несколько территориально удаленных объектов. Туда развозили обновления проектами. Но со временем выяснилось, что немножечко апликейшены разные(где-то что-то недовезли, недостиавили и т.п). Встала задача их синхронизировать. Было взято приложение- эталон, и простым копированием оно перекрывало существующее. (Приложение отличается от стадартного, 2.5 сп3 самописным модулем). Где-то всё проходило отлично - синхронизация проходила без проблем. А на некоторых филиалах при синхронизации акспата хочет удалить таблицы usr слоя. Хотя в эталоне они есть. Если предварительно накатить только эти таблицы из эталона в приложение филиала, а потом уже каталог перекрывать, то всё равно таже ругань. Если сделать отмену синхронизации и накатить проблемные таблицы, то опять при синхронизации ругается, но уже к части первоначальных добавляются новые таблицы...
Из положения вышли, накатив только usr слой. Но всё равно, никто не подскажет, как можно гарантированно синхронизировать апликейшены?

[komar]

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

[Maxim Gorbunov]

Как идея для исследований (в случае использования предложенного в качестве "гарантированного способа" ответственности не несу, предупреждаю сразу). Попробуйте эмулировать установку сервис-пака. Скопируйте файлы *.aod в папку Old и накатите новые файлы слоев. Потом делайте проект обновления приложения и дальше по списку. Может быть так удастся обмануть синхронизацию.

Еще раз замечу, что сам не проверял, и пока проверять не собираюсь, так как времени и подходящих файлов слоев сейчас нет.

[mazzy]

Zitat:

Изначально опубликовано NJD
А на некоторых филиалах при синхронизации акспата хочет удалить таблицы usr слоя. Хотя в эталоне они есть. ... но уже к части первоначальных добавляются новые таблицы...

Внутри все объекты определяются по ID, а не по именам.
В вашем случае, скорее всего, таблицы были с одинаковыми именами, а ID у них были разные. После копирования AOD, Аксапта не находила объектов с требуемым ID и соответствующим образом ругалась.

Что делать? В 2.5 - ХЗ. В 3.0 - экспортировать и импортировать проекты с ID.

А это у вас вопрос был про импорт проектов из параметров командной строки?

[Vadik]

Zitat:

После копирования AOD, Аксапта не находила объектов с требуемым ID и соответствующим образом ругалась.

Похоже, что все-таки находила, иначе что же она собиралась удалять?

Zitat:

Где-то всё проходило отлично - синхронизация проходила без проблем. А на некоторых филиалах при синхронизации акспата хочет удалить таблицы usr слоя. Хотя в эталоне они есть

А если сразу после обновления USR копированием axusr.aod синхронизовать (средствами сиквела) таблицу SqlDictionary с эталонной? (RecId придется руками сгенерить) Правда, без дополнительных телодвижений при этом съедет документооборот и другие ссылки на затронутые (те, у кого ID не совпадает с эталоном) таблицы по tableId, но если их немного, все это можно разрулить ручками (скриптами)..

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

[NJD]

Попробовал ответить при синхронизации Нет, не удалять таблицы. В результате всё нормально прошло. Данные не удалились. Следующая синхронизация уже не ругалась ни на что. Имхо можно и так делать. Ну на случай потери данны выгружать их предварительно в dat файл.
2 Muzzy - нет, это не я спрашивал про командную строку.