На предприятии используется самописная конфигурация. Структуры предприятия можно изобразить как пирамиду: Кроме головного предприятия есть 3-4 филиала, в каждом филиале есть 2-3 производственных участка. Во всех узлах этой схемы (кроме головы) используется с разной интенсивностью отдельная база самописной конфигурации.
Проблема в том, что по мере внедрения в разные филиалы конфигурация стихийно дописывалась для каждого участка и филиала и теперь это месево из различных конфигураций. Данные передаются внутри филиалов планами обмена по правилам. Есть идея объединить это все, а частности начать с конфигурации, а именно создать РИБ без обмена данными. Прежде чем создавать 12 первоначальных образов РИб и заливать туда данные. Хочу рассмотреть вариант привязывания существующих баз к головной.
Обдумываю техническую реализацию. Понимаю, что "ПланыОбмена.УстановитьГлавныйУзел(Узел)" никто не отменял, но нужен сам узел. На этапе подготовки мы придем к идеальной cf, которая будет загружена во все базы. Соответственно нужный план обмена будет во всех базах. Узким мне кажется место, где нужно узел главной базы правилами перекинуть во все остальные, а затем установить этот узел главными. В итого базы, которые изначально не входили в РИБ должны стать стать подчиненными. Как вы думаете - Взлетит? Какие подводные камни могут быть?

И это лишь всё ради чего?

Загрузи cf во все базы, огород зачем городить?

Ради начала интеграции. В последствии необходимые для обмена объекты можно включать в полный обмен.
Конфигурация постоянно разрастается и постоянно накатывать 12 ЦФ не очень удобно. Так проще делать обновления. Без РИБ больше соблазна делая дописку, накатить ее только на одну базу и в итоге снова прийти к месеву.

(2)+ какие-то базы подключить к хранилищу по возможности.

Я просто у себя отказался от РИБ, потому что при интенсивной работы он показал себя с очень плохой стороны

(3)Это не мотив ломать систему.

(5) что именно не понравилось?
Хранилище тоже не супер удобно
Основной у меня - привязывание самостоятельной базы в качестве  подчиненной. Можно и самому пробовать, но долго. Может был у кого опыт или есть хорошие теоретические знания?
(6) Что в данном случае "Ломать систему"

в чем проблема с привязкой? делай (2), привязвай

(0)
Сделай из головной распределенку с правилом обмена только cf - без данных. Потом по очереди отпочковывай базы с переливкой данных из рабочей во вновь созданную периферийку.
Обмен данными между базами на данном этапе не ломай.
После этого как минимум будет одна конфа - уже легче обновлять/дорабатывать.
Стоит ли ломать текущую схему обмена данными - не уверен...
ИМХО.

Я так делал когда получил в наследство около 20-ти "почти идентичных" баз. Обновление печатной формы первичного документа выливалось в несколько дней работы.

(9)+ Тупо подключить уже существующую базу к головной - может вылезти потерей данных.
Например в обоих конфах есть справочник "Пользователи", но внутренние ИД у них могут быть разные. В данном контексте справочник скорее всего будет пересоздан с удалением всех данных.

(10) А если базу создали копированием, и просто переименовали организацию? Вот веселья будет :)

ну есно без анализа элементарного на уиды метаданных и места типа (11) и начинать не стоит

(9) это вроде основной вариант, только не верю я в безболезненный перелив данных. Хотя признаться честно - между идентичными конфигурациями не доводилось переносить данные.
(10) Если в плане обмена не выбрано объектов для обмена данными - разве будет такая проблема?
(8) Я так понимаю это ответ "Да" на (0), там именно такая схема и описана.
(12) с уидами метаданных не сталкивался, но по плану у всех будет загружена одна ЦФ - это не поможет

(12)?

(10) как я теперь понимаю тоже идет речь об уид метаданных?

(7) В том что таблица изменений одна общая и нельзя на неё наложить управляемую блокировку.
По факту перепроводка данных по одной организации вызывала блокировку работы всей базы. Не говоря уж о том что обмен также блокирует работу. Плюс как только таблица изменений начинает расти (а это не изежно в конце отчетного периода, так как бухи перепроводят данные за 3 месяца), то начинаются странные  блокировки таблицы изменений практически на пустом месте

p.S. Речь идёт о типовой БП, может в самописке в которой работает 1,5 землекопа и этого не будет заметно


Второй момент. невозможно срочно внести изменения в конфигурацию без обмена. Т.е. по факту если нужно срочно загрузить CF то тебе нужно будет сделать обмен, и при условии что данных для обмена накопилась очень много .... это может потребовать очень много времени, неговоря уж о том, что если необходимо рочно внести изменения для нижнего уровня (производственного участка). Придётся выгонять людей со всех уровней, начиная с головной базы

(13) Речь о данных. У тебя была база в которой вели учет. Потом её скопировали удалили документы и поставили на другой участок, предварительно переименовав Организацию, подразделение, склад и т.п.

Т.е. по факту у тебя элементы с одинаковым ГУИД в разных базах имеют разное значение, и при попытки "слить" эти базы в одну у тебя получится фигня, потому что, по умолчанию, синхронизация идёт только по УИДУ.
Поэтому возникает вопрос, как понять что ИП Иванов в одной базе и ИП Петров в другой - это разные контрагенты, хотя их УИДЫ совпадают. А ИП Иванов и Иванов с разными УИДами - это один и тот же клиент и нужно данные объединить

(15) Да.
(11) Я предлагаю использовать распределенку не для обмена данными, а для обмена метаданными (самой конфой).
Соответственно если базу делали копированием, то это даже хорошо - можно попробовать в нее тупо загрузить cf и привязать через УстановитьГлавныйУзел.

(11) Да-да, мне тут такую свинку подложили с копированием баз.

(17),(18) Не надо сравнивать объекты данных, только объекты метаданных. Может я заголовок написал не понятно, но имел ввиду я именно обмен ТОЛЬКО КОНФИГУРАЦИЯМИ.

Проблема у меня в том, что не знаю я как устроен механизм РИБ на уровне платформы. И вот (10) и (12) похоже на то, что нужно.

(18) Повторяю еще раз.
Использовать ТОЛЬКО для CF - плохо, потому что для того чтобы загрузить изменения в участок, тебе нужно выгнать из главной базы, загрузить туда и сделать обмен. Выгнать из филиала всех и сделать обмен. Выгнать из цеха всех и сделать обмен.
Вместо того чтобы как раньше загрузить только в цех
И где профит?

Если в дальнейшим планируется обмен документами и справочниками - тоже не айс, по причинам выше

И да в любой типовой БП можно настроить автообновление по расписанию. Может проще оттуда выдернуть функционал?

(21) бери любую "периферийную базу" - загрузи в нее cf головной - если данные целые значит это потомок той конфы, если не целые - тогда делай новую периферийку и переливай данные.

Например вариант с хранилищем
Обновление большого количества типовых баз с помощью хранилища конфигураций
Надоело обновлять 100 типовых баз БП и ЗиУП руками? Милости просим!
(с) http://infostart.ru/public/165167/

И не надо лохматить бабушку

(24) Ну можно и через сравнения залить

Воспользовался

УИДМетаданных = ЗначениеВСтрокуВнутр(Справочники.Номенклатура);
Уид2 = ЗначениеВСтрокуВнутр(Справочники.Номенклатура.ПустаяСсылка());

в 4 базах - результат одинаковый

(27) номенклатура явно будет везде одинакова.
ты проверь на свежедобавленных объектах

Часто гуглю 1совские темы и натыкаюсь на ветки форумов без логического завершения. В итоге плодится гора бесполезного мусора, в котором все сложнее что-то найти. Поэтому отвечаю на свой же вопрос:
1. Да, данная реализация работает. Пока не могу сказать о качестве и долговечности, но технически работает. В итоге в базе, которая должна стать подчиненной создал второй узел, назвал его аналогично главному узлу первой базы, программно сделал второй узел главным:

ГУ = ПланыОбмена.РИБ.НайтиПоКоду("01");
ПланыОбмена.УстановитьГлавныйУзел(ГУ);

Обмены изменениями конфигурации без данных идут.

2. Действительно важно смотреть на УИД метаданных. Я не нашел хорошего отчета по сравнению, поэтому сделал свой.
Выгрузку/загрузку XML/XLS или COM делать не хотелось, поэтому сравнивал копируя таблицу значений с формы в эксель.
А в эксель придя к единому порядку и составу метаданных для обеих конфигураций просто делал проверку - равны ли значения в колонках, а дальше фильторм нашел "ложь". В итоге 2 справочника действительно оказались с разными УИД и данные при накатывании cf потеряны. Но там мелочь.

УИД метаданных искал вот этим кодом

&НаСервере
Процедура ЗаполнитьМетаТаблицуНаСервере()
    СтрокиМетаТаблицы(Справочники);
    СтрокиМетаТаблицы(Документы);
    СтрокиМетаТаблицы(РегистрыСведений);
    СтрокиМетаТаблицы(РегистрыНакопления);
    СтрокиМетаТаблицы(Константы);
    СтрокиМетаТаблицы(Перечисления);  
КонецПроцедуры

&НаСервере
Процедура СтрокиМетаТаблицы(КоллекцияМетаданных)
    Для каждого Мета из КоллекцияМетаданных Цикл
        НоваяСтрока = ТаблицаУИДМетаданных.Добавить();
        НоваяСтрока.МетаИмя  = Строка(Мета);
        НоваяСтрока.МетаУИД1 = ЗначениеВСтрокуВнутр(Мета);
        Попытка
            НоваяСтрока.МетаУИД2 = ЗначениеВСтрокуВнутр(Мета.ПустаяСсылка());
        Исключение
            НоваяСтрока.МетаУИД2 = "Нет ссылки пустого";
        КонецПопытки;
    КонецЦикла;
КонецПроцедуры

Столбец со ссылками на пустые ссылки(УИД2) сильно пользы не принес.