Есть несколько одинаковых баз, требуется обновлять. Довольно муторно накатывать через cfu файлы, пробовал способ через cf, все работает. От текущих релизов базы отстают на 5 версий всего. Вопрос как - все таки правильно обновлять базы?
(1) GSWF, если разрешается обновлять "через пять релизов", то можно и так. Но если изначально переход с первого релиза сразу на пятый не предусмотрен, то лучше этого не делать.
(2) bigshoma, а конфигурация поставщика при этом тоже обновляется?
А вообще, раз базы одинаковые, рекомендую подключить их к одному хранилищу и обновлять оттуда. В этом случае обновление происходит гораздо быстрее и конфигурация поставщика также обновляется.
(1) GSWF, Ничего страшного, если вы обновляете СFкой) Я например когда в одном из франей была в бегах по клиентам, клиенты которого на пиленных специальных конфах сидели, так там Пилильщик-франч выкладывает регулярно СФки обновлений, раз в пять релизов по сравнению с сайтом юзерс 1С)) и ничего.. и все работает)
(12) AnryMc, присмотритесь повнимательнее. там условия идут не исключающие друг друга.
т.е. не
Если ... ИначеЕсли ...
а
Если ... КонецЕсли; Если ... КонецЕсли; ...
(19) AllexSoft, архив может и не помочь, если косяк всплывет скажем через месяц после обновления, потому что обычно толком никто не проверяет результат обновления, еще раз акцентирую - "как правило"
(20) m-serg74, ну если уж через 20 релизов прыгаешь cf'иком то надо взять за правило все таки проверить раз в 2 года ) ну а если релиза 3-5 пропускаешь то 99,9999% будет все хорошо по умолчанию... ну и описание к релизам читать надо, они обычно пишут что нибудь в "знаковых" релизах
(7) Dima_b, эмс, дп просто через поддержку: Конфигурация - поддержка - обновить конфигурацию.. выбираем вариант из файла, выбираем наш cf и вперед, все обновляется так же как из cfu, только обновления можно пропускать (как в 7.7)
Я всегда делаю так - делаю копию базы и обновляю ее на новый релиз, проверяю чтобы все мои изменения никуда не пропали. Затем сохраняю ЦФ и в рабочей базе делаю "Загрузить конфу из файла".
При обновлении конфигурации при первом старте анализируется старый и новый номер релиза. Вызывается обработка "ОбновлениеИнформационнойБазы" которая, в зависимости от изменений, может "перепровести" документы у которых изменились мтоды проведения, обновить ставки налогов ипрочее...
Но эта обработка обновляет только "изменения" текущего релиза, пропуская предыдущие.
Если у Вас пропущены обновления (не выполнялось обновление информационной база) нужно переписывать эту обработку, что бы сделать промежуточные оьновления. Если в конфигураторе не включена возможность изменения конфигурации - её (обработку) можно сохранить как внешнюю - изменить - обновить базу.
Иногда важно чтобы изменения шли подряд, т.е. если вы уже зделали обновления для последнего релиза и пропустили предыдущие их повторное применение может дать неправильные результаты.
По-моему, если удачно сделал обновление основной конфы (или одной базы) выгружаешь сие дело в cf-файл и в другой базе надо делать "Загрузку", а не "Сравнить, объединить". Во втором случае не меняется конфа поставщика (очень полезна при сравнении доделанных наворотов перед обновлением), в первом же случае нужно всю конфу разрешить для изменения с сохранением поддержки, а потом при загрузке установить из заново за "замОк". Самое главное при таком обновлении случайно не пропустить какой-нибудь критичный релиз, иначе может возникнуть трабла в учете, которую потом долго будешь искать
Вот кусок кода из обработки "ОбновлениеИнформационнойБазы" (БП релиз 2.0.49.11):
ТекущаяВерсияИБ = Константы.НомерВерсииКонфигурации.Получить();
НоваяВерсияИБ = "2.0.12.2";
Если ((ОбщегоНазначения.ПолучитьНомерРелиза(ТекущаяВерсияИБ) = "2.0.12"
Или ОбщегоНазначения.ПолучитьНомерРелиза(ТекущаяВерсияИБ) = "2.0.11")
И ТекущаяВерсияИБ <> НоваяВерсияИБ И ТекущаяВерсияИБ <> "") Тогда
...
КонецЕсли;
ТекущаяВерсияИБ = Константы.НомерВерсииКонфигурации.Получить();
НоваяВерсияИБ = "2.0.13.5";
Если ((ОбщегоНазначения.ПолучитьНомерРелиза(ТекущаяВерсияИБ) = "2.0.13"
Или ОбщегоНазначения.ПолучитьНомерРелиза(ТекущаяВерсияИБ) = "2.0.12")
И ТекущаяВерсияИБ <> НоваяВерсияИБ И ТекущаяВерсияИБ <> "") Тогда
Показать
и так продолжается до 2.0.49
Отсюда вывод: теоретически cf-кой релиза 2.0.49 можно обновлять базу начиная с версии 2.0.11
Если не прав - поправьте
Пример: 1С решает удалить справочник АдресаСтарый и перенести все данные в справочник АдресаНовый
Вариант 1 (обновление по порядку):
релиз +1:
после обновления остается справочник АдресаСтарый и добавляется справочник АдресаНовый
после запуска предприятия обработка обновления переносит все данные из старого справочника в новый справочник
релиз +2:
после обновления удаляется из метаданных справочник АдресаСтарый
Вариант 2 (перескок через релиз):
2 варианта на выбор - либо навсегда повиснет бесполезный справочник АдресаСтарый, либо если все таки удалится, то после запуска предприятия обработка обновления не найдет откуда брать данные для заполнения справочника АдресаНовый ведь справочника АдресаСтарый физически не существует...
Зависит от того насколько вам нужны в жизни острые ощущения.
Через cf-ник обновляется основная конфигурация, но не конфигурация поставщика.
Процесс обновления предполагает собой определенную последовательность не просто так.
А потом после вас придет какой-нибудь ваш коллега, но зеленее, и запорет обновление, потому что
добавленные элементы не будут на поддержке.
А потом ведь всё равно держать в голове приходится порядок накатки обновлений.
Какие-то можно, действительно, позволить катнуть через цф, какие-то нет.
Зачем такой геморрой? Делай как положено - будет хорошо.
Через cf-ник обновляется основная конфигурация, но не конфигурация поставщика.
Обновляется и конфигурация поставщика и основная конфигурация. По сути cf от cfu отличается только тем что в cfu содержатся только отличия от предыдущих конфигураций, а в cf полностью вся конфигурация. Никаких специальных процедур, скриптов обновления и тд в cfu нет.
обновление, с пропуском релизов, больше не делаю. Был печальный опыт и бессонная ночь, чтоб понять что случилось. А случилось то, что в комплексной автоматизации, в одном из релизов была процедура, которая меняла коды доходов. Случился отчетный период, и что-то не то началось. Пришлось спешно разбираться. После этого шаг за шагом только. Лучше чуть медленнее, но без гемора. Либо надо точно знать, что никаких важных процедур не будет пропущено
Я рассуждаю о свойствах фала cf. Получается файл cf содержит только структуру конфигурации а никаких данных не содержит. В бухгалтерии 7.7 конфигурация и отчеты вообще устанавливаются отдельно. Уважаемые коллеги если у вас есть какие ни будь наблюдения напишите о них в этой ветке. Хотелось бы знать на сколько конфигурация бухгалтерии 3.0 установленная из фала cf отличается от установленной стандартным образом? К сожалению плохо знаю конфигурацию бухгалтерия 3.0 по этому и задаю здесь этот вопрос.
(38)вам надо почитать документацию по администрированию - это такие желтые книжечки вместе с программой в коробочке.
Потому как не понятно что вы имеете в виду под стандартной установкой.
ЗЫ а тема была начата в 2013 году, археологи ее откопали ... вот теперь веселимся...