Ребята. растолкуйте на пальцах как обновить правленую типовую конфигурацию. причем номер конфигурации поставщика отстает на два релиза от номера рабочей конфигурации. поиски в инете  дают массу статей, но все как-то туго. отзовитесь.

еще, файлы обновлений в виде архивов в которых есть cfu, но нет cf.

Мне бы ваши проблемы.

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

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

интересно награждается тяга к познанию.

сперва выровнять релизы поставщика и рабоч.конфигурации. Для этого нужен .cf от релиза рабочей базы

такого cf нет. есть лишь рабочая база 1.0.13.1, поставщик 1.0.11.1 и обновление от 12го до 17го. задача обновить рабочую базу до 17го релиза.

(0) Обновляй как обычно, что не так?
Только в промежуточных этапах не обновляю рабочую базу, иначе затрешь данные в добавленных реквизитах.

так вот уровень моих практический познаний в обновлении таков что мне не понятна фраза "обновляй как обычно". я поступал так: при обновлении с 13 до 14 через Конфигурация - Поддержка - обновить конфигурацию игрался с галочками о исправлениями кода. когда обновил, при попытке зайти в предприятие вылазит ошибка "Версия поменялась - запустить обработки". на них ошибка. а так же затерлись некоторые правки в рабочей, хотя галочка "Показывать только дважды измененный объекты" стояла и в поле сравнения эти отличия не попали. если можно - объясните на пальцах как поступать. сейчас склоняюсь к мысли что может сразу обновить рабочую последовательно аж до 17го релиза и там уже вносить все правки из рабочей.

при обновлении в диалоге сравнения сними все галки - так сможешь поднять релиз только конфы поставщика
после выравнивания версий поставщика и рабочей обновляешь дальше по стандартной методике
в принципе все расписано здесь http://develop.iservice.ru/articles.phtml?subaction=showfull&id=1229313407&archive=&start_from=&ucat=11&;

только не помню - для обновления конфы поставщика необходим CF или достаточно CFU

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

(11) так и делал. затерлись некоторые правки в рабочей, которых не было в таблице сравнения при проставленной галочке фильтра. сейчас у меня план действий таков. есть 13й релиз - необходимо обновить до 17го. я последовательно накатываю обновления, ничего не трогая в галочках в сравнении, каждый раз получая типовую базу без моих правок с необходимым релизом. конфигурацию базы данных каждый раз не обновляю и в предприятие не захожу. когда доберусь до 17 го релиза буду все правки руками перетаскивать из первоначальной рабочей (13) в новую рабочую (17). когда перетащу все правки - обновлю базу данных, выгружу файл конфигурации и зайду в предприятие. по идее мне должно вылезти сообщение что версия поменялась и произвести все обновления с 13го до 17го. правильно ли я размышляю и приведет ли меня такой метод к победе?

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

(14) обоснуй.

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

(15)в коде посмотри, в общем виде рекомендация верная, обработка должна работать на той коные для которой написана а не на следующей

(13)галочки птички и чекбоксы тебя не спасут
конфа переписана
смотри (12)

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

(19) ты определись как будешь промежуточные обновы делать? с сохранением нетиповых доработок или без?

(20) без сохранения. не типовые доработки буду тулить в последний релиз.

http://infostart.ru/public/18562/

(21) рискуешь, но раз так решил то тогда самый быстрый:
1) типовая конфа 17 релиза, добавляешь туда нетиповые доработки, полученный результат сохраняешь в CF_17_доработки
2) рабочая конфа 11 релиза - делаешь "Сравнить, объеденить" с полученным в п.1 CF_17_доработки. При сравнении объекты, исчезнувшие в CF_17_доработки по сравнению с Рабочая_11 не удаляй

потом когда будет время - обнови только конфу поставщика до 17 релиза

(22) не хочет он это читать :) уже советовал :)

(19)считай что ты тренируешся на копии
и опять: разница межде твоей и типовой должна быть равна разнице между твоей и типовой после обновления самы простой путь уже описан выше

то есть выходит что лучше делать обновления сразу на рабочей и после каждого шага (установки обновления) сохранять и заходить в предприятие. так полюбому не выйдет. а можно ли сделать 4 кафешки для каждого релиза (причем 14, 15, 16 будут с затертыми правками, а 17 с восстановленными). потом последовательно налить их на рабочую, каждый раз сохраняя и заходя в предприятие. как считаете, сработает ли такой вариант?

(26)
> делать обновления сразу на рабочей и после каждого шага (установки обновления) сохранять и заходить в предприятие

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

А в чем разница между этими двумя вариантами?

(26) а почему не сработает? И пользователи могут работать, когда ты обновляешься. Выгонять только на момент сохранения конфы БД.

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

(28) итого выгонять 4 раза. ))

(30) да, это если сохраняешь конфу БД каждый раз. А если например конфу поставщика или просто сохранить конфигурацию, то и не нужно.

(30)вечером можно проще - обновлять каждый раз на типовой релиз по быстрому а потом внести доработки только в последнюю конфу

(31)имеется в виду чтобы обработки обновления верно отработали