Подскажите пожалуйста как создать РБД, если в филиалах уже стоят рабочие базы, причем версии конфигураций могут отличаться?
План примерно такой?

1. Обновить все конфигурации до одного релиза.
2. Загрузить все данные из филиалов в предполагаемую центральную базу.
3. Настроить план обмена.
4. Создать периферийные ИБ и разослать их филиалам.

И можно ли как-нибудь обойтись без объединения данных?

Можно и без Объединения, пропусти пункт (1, 2) Всё зависит от того что надо получить.

В центральной базе надо получить рассчитанную з/пл филиалов. А филиалы должны получать обновления.

Сейчас у каждого своя база, со своими доработками конфигураций. Исходя из этого логично было бы сначала привести конфигурации к единому знаменателю. Как вы считаете?

И еще. Если мы перед созданием РБД не сливаем данные всех филиалов в одну кучу, можно ли базы филиалов просто подцепить к центральной без рассылки периферийных узлов, а потом уже обменяться данными?

Кто-нибудь, кто имеет опыт УРБД, подскажите!!! В инете куча информации, но найти исчерпывающие ответы на вопросы не могу :(

чтобы использовать РБД необходимо чтобы конфигурация в периферийных базах совпадала с конфигурацией в главной базе. у каждой базы есть свой GUID, на основе которого и смотрится что эта РБД является наследником центральной. т.е. после того как загрузили всю инфу и есть центральная база, выгрузить конфигу из центральной базы и разослать ее всю филиалам. там накатить эту конфигу и сделать главным узлом центральную базу.

Такой интересной задачей не занимался. Но имхо если конфы будут везде одинаковые - то в конвертации данных нарисовать правила выгрузки будет проще, выгрузить данные в новую базу (или в центральную), наделать начальных образов и разослать филиалам. (2) Интересная мысль, по идее можно прицепить все к одному узлу (имхо, опять же желательно что бы были одинаковые релизы), потом в журнале регистрации включить регистрацию всех объектов и прогнать обмены. Мне кажется данные начнут курсировать в обменах

+(4,5) Если у тебя на тестовых копиях центра и одного филиала взлетит, то значит можно, надо просто взять и попробовать:)

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

+ (7) Конфа должна быть единой. т.е. тебе сначала надо сделать общуюю, устраивающую всех конфу, получить её cf. Далее на сестах этот cf применить,
далее создать пустую базу , сделать её ЦБ, далее в филиалах эти базы сделать ПБ, зарегить нужные данные, провести обмен и вуаля.

Проще написать какую-нибудь выгрузку, которая будет кидать нужно из конфы в конфу. После в центральную базу перенести данные и создать распределенные. Или вообще не заморачиваться на УРБД, а обойтись самописной выгрузкой.

С самописными выгрузками приходится изобретать велосипеды с синхронизацией справочников. УРБД в этом отношении гораздо универсальнее.

Спасибо за ответы! Буду пробовать.

Если есть еще мысли или полезные ссылки, выкладывайте!

(10) пока не случилася херня и УРБД отвалились, и каждому филиалу опять надо прислать cfник. потому как конфигурация не соответствует ожидаемой

(12)Отваливалось за полтора года всего один раз, при кривом динамическом обновлении (админы решили сервак на ходу перезагрузить). А так никаких граблей не было. Интенсивность обменов - каждые 15 минут, с 8 утра до 9 вечера. Активно юзал динамическое обновление конфигурации

(11) Выкладываю :)

У автора разные конфигурации (не важно что у них общий предок)? Тогда можно использовать универсальный механизм обмена данными между _разными_ конфигурациями. Создание первоначальных образов - не обязательно. Использование КД - обязательно. Синхронизация справочников и документов - желательна.

Если автор во всех базах добъется идентичности конфигураций - тогда можно говорить о механизме РИБ-обмена (с переносом изменений конфигурации). Но данный обмен использует соответствие объектов по уникальным идентификаторам. Придется базы сливать в одну с использованием КД2; причесать через данные (например: удалить дубли) а потом - создавать первоначальные образы...

PS: В любом случае автономные базы, перед создание распределенной базы, потребуют синхронизации по данным так или иначе...

(12), от 2 до 5 лет с разными ПБ, с интервалом в 2 часа идут обменты, 9 ПБ. Только один раз было подобное. При весе конфы около 45МБ. Всё было починено быстро.

(14), да, это большой труд.
Вообще сильно зависит от сути внесенных изменений в конфы. Может быть только сливать через КД, а если только "рюшечки" и "мелкие хотелки", то и нет, в общем смотреть, думать, делать.

Объединить конфигурации не проблема. Останавливаемся на РИБ, т.к. проще обновляться и , как мне кажется, обмениваться данными.

А вопрос про создание РБД не выгрузкой периферийных узлов, а первоначальным их подцеплением к ЦБ и затем уже обменом данными возник потому, что один из филиалов находится в сибири у черта на куличиках, и связь с ним крайне плоха. К тому же у предприятия существует ограничение на размер передаваемых данных.

(16) доставить туда конфу. применить. Подцепить к ЦБ. И по частям, по кусочкам данные перегнать в ЦБ.

Давайте попробуем разобраться в механизме "подцепления к ЦБ". Каким образом это делается?

(18) значит определить главный узел.

в планах обмена создать узел с кодом =  код главного узла. Далее назначить его главным.
Примерно так
ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаСозданныйУзел);
Всё. База "подцеплена", разумеется ЦБ для неё узел тоже создать нужно.

Ладно, с помощью N-го кода назначили подцепляемой базе центральный узел. А в центральной создали периферийный.
Далее, в периферийной базе нужно неким образом зарегистрировать изменения нужных для выгрузки в ЦБ объектов и отправить сообщение в ЦБ, чтобы та эти данные приняла. Так?

да так. и сформировать выгрузку из периферии. только сначала выгрузить из ЦБ чтонибудь, чтобы проверить, что данные загрузятся в периферии, а то зря прождете часик, а потом напишет что конфигурация не соответствует ожидаемой.

"К тому же у предприятия существует ограничение на размер передаваемых данных" - не вижу проблем. Файл можно "накрошить" и передавать по частям.

(уже уходя) Сорри, повторю: при стандартом риб-обмене соответствие объектов идет по уникальным идентификаторам.

Если базы работали в автономном режиме - не найдете вы там объектов с идентичными идентификаторами. Даже если у этих баз был общий предок или одна из них является предком другой, - новые добавленные объекты не идентичны по идентификаторам. Еще хуже - когда общие объекты переименовывают.

(24) справочник Номенклатура в одном != справочнику Номенклатура в другом чтоли? =)

(24) обычно справочники контрагентов пересекаются в филиалах где-то процентов на 5. Поэтому на это можно спокойно забить. Потом спокойно допиливается при помощи обработок.

Т.е. получается самый надежный способ - сначала объединить все данные, а потом выгрузить ПБ из ЦБ.
А "подцепление" чревато несовпадением уник.идентификаторов общих объектов (если таковые имеются) которые могут задвоиться.

Отсюда вывод - следует внимательно тестировать.

(27) это если ты асс в области КД. Если новичок, то наоборот.

Я совершенно не асс в конвертации :( Думала, сначала попробовать перенести данные типовыми обработками. Если не получится, тогда уже пробовать другие средства.