полное название темы: "Обновление конфигурации рабочей базы с помощью заранее подготовленного  файла cf методом «Загрузить конфигурацию из файла»"

Доброго дня, уважаемые специалисты! Прошу подсказки знающих людей.
Конфигурация рабочей базы – Бухгалтерия, ред.3., измененная типовая, с поддержки не снята.

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

1. Исходный релиз - 3.0.60.44. Из таблицы на сайте обновлений 1с вижу, что до актуального релиза нужно сделать 2 обновления: 1-на релиз 3.0.61.47, 2-на релиз 3.0.64.21.
2. выгонять надолго пользователей из рабочей базы и выполнять обновление конфигурации нельзя
3. Делаю копию рабочей базы для обновления конфигурации
4. скачиваю релиз обновления 3.0.60.44
5. Захожу в конфигуратор, жму «Конфигурация – Поддержка – Обновить конфигурацию».
Запускается процесс сравнения, объединения конфигураций. Жду завершения процесса, принимаю изменения конфигурации, вношу нетиповые изменения, если таковые затерлись.
6. Запускаю 1с в режиме предприятия, выполняются обработчики обновления. Пробегаюсь по измененным объектам, проверяю их работоспособность. Можно приступать к обновлению конфигурациии рабочей базы
7. Выгружаю обновленную конфигурацию в файл.

Вопросы:
1. возможно ли произвести обновление конфигурации рабочей базы путем загрузки  файла cf, подготовленного на этапе 7 ? (ведь критичных промежуточных релизов никаких при обновлении никаких не пропущено)
2. Все ли обработчики обновления в таком случае выполнятся корректно?
3. Хочу использовать этот метод загрузки подготовленной обновленной конфигурации из файла потому, что обновление рабочей конфигурации через сравнение/объединение идет гораздо дольше. Да и зачем его повторно делать, если с помощью этого метода я подготавливал обновление конфигурации на копии базы?
4. Обновление усложняется тем, что имеются распределенные базы, план обмена = ПоОрганизации. Поэтому планирую делать так:
-обновление конфигурации главного узла на релиз 3.0.60.44
-выгрузка файла обмена из ГлавногоУзла для ПодчиненногоУзла
-загрузка файла обмена в ПодчиненныйУзел (в этот момент происходит обновление конфигурации, выполнение обработчиков обновления), выгрузка файла обмена из ПодчиненногоУзла для ГлавногоУзла
-загрузка файла обмена в ГлавныйУзел

-обновление конфигурации главного узла на релиз 3.0.64.21
-выгрузка файла обмена из ГлавногоУзла для ПодчиненногоУзла
-загрузка файла обмена в ПодчиненныйУзел (в этот момент происходит обновление конфигурации, выполнение обработчиков обновления), выгрузка файла обмена из ПодчиненногоУзла для ГлавногоУзла
-загрузка файла обмена в ГлавныйУзел

загрузить конфигурацию? для обновления? вы серьезно?

(1) а что не так?

(2) после этого БД можно выкинуть

(3) Почему?

(2) Я всегда так делаю. 1С давно уже нормально объекты сопоставляет

Да Вы, батенька, экстремал. А чем стандартный механизм обновления не устраивает? Выполняется дольше, чем накатить CF? А как потом быть с GUID'ами, которые с большой степенью вероятности поедут в разные стороны?

(3) Обоснуй.

потому что сравнение идет по идентификаторам объектов метаданных, а загрузка их просто заменяет

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

(9) можно и без этого, используя тот cf что создал ТС, но через сравнение и не забыть про конфу поставщика

1. Да, если обновление очередным релизом - возможно;
2. Нет, после загрузки конфигурации нужно запускать сеанс "1С:Предприятие" из-под пользователя с административными правами;
3. Обновление конфигурации копии рабочей базы, выгрузка и загрузка в рабочую базу не противоречит рекомендациям методистам(имхо);
4. Это не играет роли так, как к теме "обновление через загрузку" не относится. Миграция обновления конфигурации в РИБ тоже можно сделать отдельным батником.

PS: я так и обновляю конфигурации рабочих баз - поднимаю копию из архива, обновляю, запускаю обработки обновления и проверяю сохранность данных и работоспособность (конфигурация с изменениями); только после всего этого - обновление рабочих баз.

(9) А в таком случае он не будет снова сравнивать как при обычном обновлении?

(10) Я говорю, как лучше, а не как можно.

(12) Не будет, если в твоей рабочей базе будет отключена возможность внесения изменений.

Еще можно заморочиться с хранилищем конфигурации.

(13) Это не "лучше", это "сложнее". Не надо усложнять самому себе жизнь и выдумывать проблемы там, где их нет.

(14) Так конфигурация же доработанная. Разве можно навесить на нее замок?

(17) читай (9)

(16) Ты в праве заблуждаться так, как считаешь нужным.

Если считаешь что что-то для тебя слишком сложно - не пользуйся этим и все.

Все попкорном запаслись?

(19) Ты в праве городить лишние сущности, игнорируя бритву Оккама.

(22) Скажи еще что-нибудь умное.

(6) Что будет если GUID вдруг поменяется при загрузке конфигурации из файла?

(0) Когда нарвёшься на гемор, поймешь, что семёрочный подход чреват потерей данных.
Если коротко и без объяснений-так не надо.
Лучше добейся выделения времени на регламентные операции для пользователей и делай по порядку.
На время обновления для РИБ очень рекомендую отключать автоматическую синхронизацию.

(23) Правило форума: "Не переходить на личности."

(26) И вам не хворать.

(24) зависит от платформы. На старой платформе будет попа, на новой, ничего страшного

(24) В базе могут повсплывать "Объект не найден"

"Идентификатор в пределах одной конфигурации никогда не изменяется. Идентификатор не изменяется при выгрузке конфигурации в cf или dt файлы (включая файлы поставки cf и обновления cfu). Идентификатор не изменяется при использовании механизма групповой разработки (в процессе перемещений между конфигурацией и хранилищем). Идентификатор всегда изменяется при копировании объекта, в том числе в процессе объединения конфигураций"
Источник: https://its.1c.ru/db/metod8dev#content:2299:hdoc

(28) что есть "старая" в вашем понимании?

(24) А как эти guid'ы могут поменяться?

вот в (30) и ответ поступил.

(32) получается он может поменяться и при обычном обновлении?

(33) Нет же. Можно выгрузить конфигурацию и загрузить, применяя обычную загрузку.
(3) считаю не обоснованным выводом.

(31) понятие не имею. Просто знаю что после какого то момента это перестало быть проблема. А вот точный номер переломного релиза, я не могу назвать

(29) Мы про ГУИД методанных, а не данных

Призываю (3) и (6) аргументировать свою точку зрения.

(37) ответ в (8) чем-то не устраивает?

(0) Операцией "Загрузить конфигурацию из файла", кстате, пользуемся давно. Обновляем таким образом порядка 20 баз по мере поступления новых релизов от 1С.

(37) Так исторически сложилось, достаточно для обоснования?
Ранее (условно до платформы 8.2) такое место имело быть. Т.е, если были разные ГУИДы удаляла объект и создавала такой же с таким же именем, попудна утаскивая с собою в NULL все данные хранящиеся в этом объекте

(0) Твой вариант вообще единственно рабочий, т.к. 1с ничего другого не придумала (кроме хранилища конфигураций)

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

А как теперь в продакшен? А никак - только загрузкой cf.

Ну единственный момент - критичные релизы пропускать не нужно.

(38) Проверил гуиды в рабочих базах и старых копиях. Всё на месте.

(42) ты про какие гуиды, чем и как проверял

(35) http://v8.1c.ru/83compatible/

Предупреждения типа "Внимание! Версия... предназначена для использования с версией платформы... (и более поздних)" никуда не делось и по прежнему актуально :)

(38) А там нет объяснения с чего бы вдруг гуиды уже существующих объектов могут поменяться

(44) а это тут каким боком? Каким боком изменения функционала платформы к гуидам?

(45) потому что cf от левой базы, не имеющей отношения к оригиналу

(38) в принципе если загрузить конфигурацию, ничего не слетит.  Потому что разные ГУИДы могут проявиться только на этапе обновления конфигурации базы данных. А это следующий этап.

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

(47) какой еще левой базы? Это cf той же самой базы

(38) Можете привести схему эксперимента в результате которого при данной схеме обновления (копирование базы - обновление - копирование конфигурации) на платформе 8.3 вдруг помянеются гуиды?

(46) Это к Вашему диалогу с golem14 по поводу "старых" платформ и "полной попы" :)

(43) Сообщить("GUID = " + СсылкаНаНоменклвтуру.УникальныйИдентификатор());
Выборочно

(52) так это гуиды данных, а мы говорим про гуиды метаданных

Я не исключаю, что в новых версиях 1с допилила GUIDы но мне приносили (лет 5 назад) базу на посмотреть/починить. Файловая, размером около 3 ГБ. При запуске тупо вываливалось окно "файл с базой поврежден". ТИИ ругался на кучу несовпадающих GUIDов, причем с каждым следующим ТИИ их становилось только больше. На вопрос, отчего так вдруг, кто принес базу сказал что сначала базу обновили на копии, из копии выгрузили CF, и этим CF обновили боевую. И все хорошо работало. Но потом боевую обновили стандартным способом и вот тут то это все и повылазило. Восстановить базу никакие ухищрения не помогли, но бекап этот человек уже делал, поэтому отделались относительно легко.

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

(53) как их посмотреть?

(0) я делаю так:
1. Копию базы обновляю постепенно (через поиск обновлений) до последнего релиза, восстанавливаю потери доработок. Проверяю их работу. Потом сохраняю .cf
2. Рабочую базу обновляю постепенно (через поиск обновлений) на последний релиз вообще не обращая на потерю доработок, т.к. добавленные реквизиты никуда не пропадут, а модули не важны на этом этапе.
3. Рабочую через "Сравнение и объединение с конфигурацией из файла" сравниваю с моей .cf и обычно там вылазят лишь чисто доработки. Их накатываю и всё - готово.

(54) Sorry, не совсем в тему. ТиИ и GUIDы данных - не в тему. А по теме: от сбоев и глюков при обновлении файловой версии никто не застрахован.

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

(56) ответ на этот вопрос противоречит лицензионному соглашению )))

(54) С вероятностью 100% "этим CF обновили боевую" через сравнение- объединение. Вот тогда совпадение ГУИДов никто не обещал.

(58) ТИИ у нас хоть запускался, chdbfl сразу закрывался сам без каких либо ошибок.

(57) я тоже так делал до сегодняшнего дня, но захотел сократить время на этапе 2 (на вашем этапе 2)

Поэтому и создал эту тему. Ибо хочу делать обновление через "Загрузить конфигурацию из файла", т.к. на это требуется гораздо меньше времени, чем на сравнение/объединение

(60) об этом хозяин базы умолчал.

Можно и через загрузить. Но вначале нужно будет выгрузить конфу из рабочей.
если хоть раз сделаешь через обновление, то грузить уже будет нельзя

(57)Делаю так много лет, проблем нет. Только обновлять надо актуальную копию и не пропускать критичные релизы.

(62) так не рекомендуется делать.

(64) вот подстава то будет последующим программерам, которые об этом знать не будут )))

(64)+100

(0) Девушка! Не сомневайтесь, все будет хорошо!
По секрету сказать ВСЕ распределенные базы именно загрузкой CF и обновляются.
З.Ы. Тему пока не читал, ибо букв много. Но сейчас прочту.

(67) в чем подстава? они могут как хотят.

(70) вновьпришедший сделает обычное обновление

Если все вермя делать через обновление, то последуещее подключение копии рабочей к хранилищу может убить некоторые объекты.
Поэтому лучше грузить (или через поставку. что по сути тоже самое)

(71) И ка ему это помешает?

(56) Выгрузить конфигурацию в файлы. Там всё видно.