Добрый вечер.
Есть ЦБ и несколько периферийных баз с обменом через РИБ. Конфигурация типовая. Необходимо обновить несколько ключевых релизов. Подскажите, по опыту, как лучше сделать: накатить все релизы на центральную базу, а потом сделать одну выгрузку по РИБ в периферию или выгружать в после каждого ключевого релиза?

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

Новые базы создать после обновления не предлагайте, много всяко разного оборудования, геммора будет много

Я бы по одному делал.
НО это моё личное мнение

"Я бы по одному делал" +1

Ключевые релизы - на то они и ключевые, чтобы через них не перепрыгивали. Будь то центральная или подчиненная базы - это не принципиальный вопрос. Это чисто теоретически.

А на практике нужно смотреть на обработки обновления и запускаются ли они при последующих обновлениях. И если какая-то обработка запускается только один раз и отсутствует в последующих обновлениях  - то делайте выводы сами.

И, да, вот что ещё: РИБ - это идентичные конфигурации, но не данные - данные могут быть не идентичные в различных узлах РИБ.

При обновлении отключи сначала автоматическую синхронизацию. Это особенно критично, когда слабый интернет на перифериях.

(2) "если какая-то обработка запускается только один раз и отсутствует в последующих обновлениях  - то делайте выводы сами" // Неужели бывает так, что в модулях конфигурации более свежего релиза нет каких-либо обработчиков обновления, присутствующих в более древних релизах? В пределах одной подредакции (например, УТ 11.1) по крайней мере.
Ну т.е. херак - обновили 11.1.2 на 11.1.9, в которой нет какого-нибудь обработчика обновления, который есть в версии конфигурации 11.1.5. Это сюр.

(5) ты пришел на форум 1сников... тут за 20к никто даже с дивана не встанет, не то что на сайт заходить...

баньте это...

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

(4) "Это сюр" - нет, это не "сюр", а "маловероятно, но не исключено". Автор не озвучил ни свою конфигурацию, ни свою версию (вопрос чисто теоретически как я понимаю) и не исключено, что ему попадётся именно такой редкий случай.

Вот пример из последних обновлений ЗУП 3.1.5:
3.1.5.171 - 3.1.5.212 - 3.1.5.222 - 3.1.5.250 - 3.1.5.272
Все эти обновления - "ключевые" и обновляют только одну версию - предыдущую. Стесняюсь спросить - "А на хрен так было сделано?"

Несколько раз обновлял КА 1.1 сразу по 5-6 релизов - с подчинёнкой всё ок

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

или например старый обработчик обрабатывает какой-то регистр, а этого регистра в новом релизе или вообще нет или переименовали. И перетасовали измерения.

(0) А конфигурация какая?

(9) Так это всегда так было в любой конфе (что обнову cfu можно накатить только на какой-то один максимально древний предыдущий релиз, а на более древние - нельзя), что не мешает сразу загружать cf нужного релиза и не думать о последовательном обновлении - за исключением каких-нибудь нюансов :) Но сейчас придет zak555 и в очередной раз расскажет, как он кучу раз так делал и пробелм не знал (что конечно же не исключает вероятность их появления).

(11) Да, про платформу очень хорошее замечание - если релиз предполагает смену версии платформы, то при перепрыгивании вероятность появления гемора значительно возврастает.

Вот же Вы упёртые. Вы почему-то исходите из допущения, что в центральном узле находятся все данные подчинённых узлов.

А я смотрю в план обмена и вижу, что не все метаданные мигрируют. Значит эти данные в информационных базах имеют право быть различными! Я даже не говорю о том, что есть планы обмена "по организациям",  "по подразделениям" и т.д.

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

Конкретный пример из практики работы с УПП:

Реквизит документа был с типом "Перечисление", а потом стал с типом "Справочник" - два "ключевых" обновлений. Это было сделано двумя "ключевыми" обновлениями.

Первое обновление: добавлен справочник; реквизит документа стал комплексного типа (Перечисление, Справочник); обработками заполнили справочник значениями перечисления и перезаполнили реквизит документа с изменением значений перечисления на аналогичные значения справочника.

Второе обновление: реквизит сделали с типом "Справочник" (обработок обновления при этом не требуется)

Если в подчинённом узле "перепрыгнуть" через первое обновление, то есть риск потерять данные. объяснять далее "Почему?" или сами уже поняли?

(16) 1С на партнерских семинарах усирается, что эти времена в прошлом (в типовых на УФ типа исключены).
Во временя типовых на ОФ такое конечно бывало - нечасто, но бывало.

Sorry, мне всё равно, что они там говорят - я смотрю в конфигурацию и вижу что есть на самом деле :(

Просто пример (не в тему ветки): в моей конфигурации УПП, как мне кажется :) не предусмотрена корректная работа механизма конфигурации "Версионирование" в режиме распределенной информационной базы. Почему? Потому что регистр сведений "ВерсииОбъектов" имеет измерения "Объект" и "НомерВерсии", где "НомерВерсии" - тип "Число" и как бы префикс узла всунуть некуда :)

Вы скажите "Ха! Это же УПП - реликтовый доисторический мамонт"... Открываю ЗУП 3.1... всё тоже самое.

(18) Версии вроде не мигрируют по РИБу?

А вы проверьте :) Измерение - число, регистр включён в состав плана обмена :(

В свежих конфигурациях разработчики "выкручиваются" через установку дополнительного свойства "РегистрироватьНаУзлахПлановОбменаПриОбновленииИБ" в Ложь (оно отключает регистрацию).

Версии мигрируют (синхронизируются) полностью. Т.е. в любой инфобазе можно смотреть все изменения, в т.ч. происходившие в чужом узле

Сименс вообще плевал на всех, на санкции, на законы.
если нужно и взятку даст и поставит товар

(21) Бинго!

(офф)
Вообще-то это интересная тема сама по себе. Например, ситуация, когда сами объекты не мигрирую в плане обмена, а версии этих объектов? Должны ли они мигрировать или нет? Это интересный вопрос :)
Или, например, в планах обмена (а в свежих конфигурациях есть поддержка) предусмотрена конфликтная ситуация, когда объект может быть измененён в нескольких узлах между сеансами обмена. А как с этим дело в версионирование? Это тоже интересный вопрос :)

(23) Конфликты (коллизии) в подсистеме обмена данными БСП разруливаются так: если это РИБ, то приоритет у ЦБ. Если это не РИБ, то приоритет у инфобазы-отправителя. Плюс есть возможность переопределять эти правила (в переопределяемых модулях).

В ЗУП 3.1 коллизии регистрируются и есть возможность юзверу их "разрулить" вручную, выбрав тот или иной вариант. Речь не об этом - речь как это всё "отображается" в версионирование. Собственно говоря, никак. Оно тупо регистрирует версии по мере изменения объектов.

В свежих конфигурациях добавили реквизит "Синхронизируется" в регистр сведений. Это такой технический реквизит, который используется при выгрузке данных в РИБ. Для новых версий - "Истина", для прежних версий - "Ложь".

Sorry, за оффтопик, завязываю.

Так в БСП не "версионирование", а "История изменений" гиперссылка называется. Там конечно же отображаются только то, что привело к изменению объекта.
Но подсистема "Версионирование" для фиксации и разруливания коллизий как раз используется.