Есть РИБ из Розниц. Обновляю раз в год. Отключил синхронизацию на главном узле и последовательно обновил Розницу с версии 2.3.17 до 2.3.20. Включил синхронизацию обратно и на подчинённые узлы прилетело сразу обновление 2.3.20. Обновление на подчинённых узлах прошло успешно. Раньше я обновлял главный узел до следующего релиза, дожидался, когда обновятся подчинённые узлы и только потом обновлял главный узел до следущего релиза и опять ждал, когда обновятся все остальные узлы и т.д.

Это вообще рабочая схема сперва полностью обновить главный узел откуда потом прилетает одно обновление до последнего релиза на подчинённые узлы без промежуточных обновление?

(0) Это рабочая схема для уничтожения всех данных и повреждения базы.

Правильно после каждого релиза проводить полный обмен.

(1) Ясно, спасибо. А счастье было так рядом)

(0) Схема рабочая. Делал так несколько раз с Розницей

(3) Это до первого краха.

(3) а обработки первого запуска после обновления ИБ которые иногда половину базы переворачивают с ног на голову чтобы привести данные в соответствие с новой конфигураций придумали дураки и для дураков да?

(3) Рисковый Вы чувак!

ChatGPT тоже дурак, его приходится учить:

Итого всеми этими ИИ в вопросах чуть более сложных чем тривиальные - надо знать какой ожидается результат, чтобы оценить адекватность результата. В чем тогда смысл аких помощников? Чисто технологический там где реально просто тупо можно проверить результат? типа "напиши программку на питоне которая выводит на экран синий квадрат" - если вывел желтый - ну да, понятно что ии скосяпорил... а если использовать ии как советчика/консультаната - надо четко знать в каких областях можно доверять результату, а в каких - нет...?

(8) да

(9) понял, спсб.
как помощник в программировании - помогает, народ доволен, особенно там где не очень специалист

(8) Это как обработки на Инфостарте - нужен напильник, иначе не работает, но писать с нуля долго.

(7) Вы его не учите, а заставили сказать то, что вам хочется услышать (по его "мнению"). Известная проблема всех современных ИИ: поддакивать и соглашаться. Мне маршрут нужно было проложить в Египте между тремя широкоизвестными достопримечательностями в трёх населённых пунктах на расстоянии км. в 200. ИИ не смог этого сделать, потому что на первое же моё замечание он согласился, хотя путаница могла возникнуть из-за схожих названий храмов в разных концах Египта. В итоге он просто начал соглашаться с моими запросами касательно маршрута, если в запросе присутствовала возможность решения (а она присутствовала, потому что маршрут я знал, но меня интересовало наиболее оптимальное решение). У меня тогда мелькнула мысль, что с таким же успехом я могу его заставить согласиться, что столица Нидерландов это Вена. Проблема серьёзная и обсуждается. Что мне говорит ИИ, то, что я хочу услышать или объективное решение поставленной задачи?

(12) Поддерживаю. Они всегда соглашаются, лишь бы отстали со своими вопросами...

(5) Типовые тоже не дураки пишут. В конфе этих обработок как правило достаточно чтобы перейти почти с любого релиза на любой в рамках одной редакции. А метаданные "Удалить..." удаляются между редакциями
Исключения конечно бывают, но это вопрос оценки рисков и проверки результата, а не табу "нельзя пропустить ни одного релиза"

(14) >Типовые тоже не дураки пишут
Типовые пишут обычные люди
Которые тоже часто ошибаются как и все

Обычно лучше потратить чуть больше времени чем поторопиться и получить проблем
Когда при скачке сразу на несколько релизов обработчики обновления в ПБ будут падать
А ЦБ уже давно обновлена и там работают вовсю - пусть и бэкапы есть но хрен откатишь легко

(0) Сразу два косяка

1. Обновлять всегда надо последовательно с запуском в режиме предприятия
В случае РИБ после каждого релиза выполнять синхронизацию дважды ЦБ > все ПБ > ЦБ

>Отключил синхронизацию на главном узле
2. Нахрена???
Обработчики обновлений должны знать есть РИБ или нет!
Чтобы правильно выполнять действия и регистрировать к обмену нужные объекты!

(16)+ Отключать синхронизацию и выводить из РИБ изредка требуется только для ПБ
Когда большое обновление тяжелой конфы типа ERP не пролазит по РИБ
В этом случае да, вывел ПБ из РИБ, обновил из cf (выгруженной строго из ЦБ), снова ПБ в РИБ и запускаем обмен

(15) Которые тоже часто ошибаются как и все
Так обновляясь последовательно ты и соберешь всё их ошибки)

Обновлял Розницу с 2.3.8 на 2.3.21 cf-ом, правда не РИБ. После обновления заметил, что в справочнике подключаемого оборудования не заполнился новый реквизит значением по умолчанию - выяснил, что в одном из релизов этот обработчик просто выпилили, а в целом в коде есть обработчики аж с версии 2.2.3. Если бы это был РИБ, то в подчиненные узлы также выгрузилось бы изменение конфигурации, как и при любом другом обновлении и также бы выполнялись обработчики, как в главном узле.
Касаемо пропусков релизов, то для УТ и КА фирма 1С сама благословляет обновлять пропуская несколько релизов, но есть ключевые релизы, которые нельзя пропускать.
Если запустить обновление из предприятия из раздела интернет-поддержки, то можно увидеть, что обработка обновления сначала выкачает все cfu и потом будет поочередно их накатывать, а выполнять обработчики обновления будет только в финале, а не после применения каждого cfu, что равносильно обновлению из конфигуратора через cf.
Было как-то, что при обновлении с пропуском релизов появилось сообщение о недопустимой попытке обновления с такой-то версии. А минимальную версию, с которой можно обновиться на желаемый релиз, можно подсмотреть в процедуре ПриОпределенииВозможностиОбновления общего модуля, который в каждой конфе свой, например, для УНФ это ОбновлениеИнформационнойБазыКлиентПереопределяемый

(18) но так ты соберешь ТОЛЬКО их ошибки а не добавишь потенциальный крах данных из за пропуска релизов который они не предусмотрели.
я помню обновлял ДО 1.2 до 2.1 не помню уже конкретных версий.
неделю заняла подготовка промежуточных релизов. все что можно было выброшено, обработки запуска объединены, но из за существенных изменений метаданных из 15 +/- обновлений все равно пришлось сделать 4, которые уже было не убрать.
окно для обновления было маленькое. 15 обнов никак не укладывались.

(20) Крах не потенциальный, а вполне конкретный.
Об этом собственно и речь в (14), оценить и сделать 4 вместо 15. А в 99% случаев будет просто одно обновление вместо N.

Есть такое понятие - "ключевые релизы". И рекомендация не "перепрыгивать" через них при обновлениях. Это актуально для РИБ вдвойне, ибо узлы могут отличаться наборами данных друг от друга и то, что не принципиально для главного узла, может привести к потере данных в подчинённых узлах.

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

PS: всё упирается в вероятность возникновения проблемы. Вы можете уменьшить или увеличить эту вероятность, - главное не доводить её до 100% возникновения :)

(0) Поставь Обновлятор 1С.

Настрой обновление, после обновления выполнять скриптом обмен (тут файловый случай приведен)

@jobs_run(
    only_using:False,
    descriptions:"Выполнение обмена по сценарию: Сценарий синхронизации для Филиал ООО Рога",
    names:"",
    wait_for_completion: True,
    timeout_minutes: 30
)


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


@jobs_run(
    only_using:False,
    descriptions:"Выполнение обмена по сценарию: Сценарий синхронизации для АО "Рога"",
    names:"",
    wait_for_completion: True,
    timeout_minutes: 30
)
%conf1c% /UpdateDBCfg -Dynamic- :: обновление конфигурации базы данных


-----
Остальное как фантазия позволяет)