пятница, поэтому прошу снисхождения за дурацкий вопрос...
вот бухгалтерия 2.0 ред типовая... есть полная конфигурация новая и рабочая база с релизом полугодовалой давности
велик соблазн просто обновить последней версий :)
1. как просто понять можно ли это делать ?
2. или проще ВСЕГДА обновляться ТОЛЬКО рекомендуемыми "ступеньками" ?
3. на 7.7 спокойно обновляю хоть 5детний релиз (редакции 4.5 бух) а тут заманаться можно за год сменилось куча релизов, каждый накатывать последовательно ?
4. раскройте тему, 1С с высокой долей вероятности НЕПРЕДСКАЗУЕМО меняет объекты делая несовместимым непоследовательное обновление ?
5. пишется ли при обновлении наподобие "было некорректное обновление, рекомендуем обновить корректно" ?

вопрос-бонус :)
6. как аргументируете фрустрацию клиента "Как же так, 8ка более современная программа чем 7.7, а времени и денег за обновление получается БОЛЬШЕ " ?

Последний очень прост. "Затем и сделано".

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

(1) Ну да. а калькулятор вообще обновлять не нужно!!!

На мой взгляд, лучше всегда обновлятся последовательно, причем обязательно с запуском в режиме предприятия. Иногда бывают ситуации, когда меняются/добавляются/удаляются метаданные. И перенос из старых в новые осуществляется посредством обработок, которые запускаются в режиме предприятия после обновления. Если накатить далекий релиз, то этих обработок от старых обновлений уже нет, в итоге есть риск просто потерять данные. Давным-давно я сам столкнулся с такой ситуацией. С тех пор обновляю только последовательно. Времени на понимание, какие метаданные изменились и можно ли накатить последнюю цфку уйдет намного больше, чем сесть и не нервничая накатить 10 релизов. Хотя на Мисте куча людей, которые кричат, что постоянно накатывают релизы и у них все пучком. Либо везунчики, либо врут :)

(1) это не баг, это фича)

(0) пол-года - это не серьёзно.
Бухгалтерия вообще не критична к перепрыгиванию через релизы в отличии от УПП

(5) (Времени на понимание, какие метаданные изменились и можно ли накатить последнюю цфку уйдет намного больше, чем сесть и не нервничая накатить 10 релизов.)
Это если конфа не изменена, или изменена минимально. Начиная с релиза 2.0.40.7 я ни разу не столкнулся с удаленными метаданными. Некоторые объекты просто стали начинаться с удалить...., но обработка обновления ИБ прекрасно отработала.

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

(8) +1

>пишется ли при обновлении наподобие "было некорректное обновление, рекомендуем обновить корректно"

просто сломается... в журнал рапортует если успiх

(0) Вероятность сабжа > 0. Но есть статьи как грамотно обновляться пакетно использую конфигурацию поставщика. Гугл в помощь.

(8) БП2 просто не развивается, только поддержка изменений законодательства и исправление ошибок, поэтому удаление реквизитов и не встречается последнее время. А вот (5) наверно сталкивался с ситуацией, когда в старом релизе есть реквизит, потом в следующем ему добавляют Удалить и данные переносят в другое место. Ну а в следующем релизе уже удаляют ненужный реквизит. Вот как раз в таком случае при обновлении на самый последний из cf попадаешь на потерю данных.

(0) недавно обновлял бух-баз-2.0.. не дает, зараза, обновлять, прыгая через релиз!
так и пришлось заставить админов скачивать в порядке, следующем из таблицы, что на сайте юзер1св81ру

а сегодня вторая база позволила себя обновить автоматически!
полтора часа ожидания, и вот что она насообщала:

Выполняется обновление информационной базы с версии 2.0.51.10 на версию 2.0.52.7
Выполняется обновление информационной базы с версии 2.0.52.7 на версию 2.0.53.10
Выполняется обновление информационной базы с версии 2.0.53.10 на версию 2.0.54.13
Выполняется обновление информационной базы с версии 2.0.54.13 на версию 2.0.55.7
Выполняется обновление информационной базы с версии 2.0.55.7 на версию 2.0.56.4
Выполняется обновление информационной базы с версии 2.0.56.4 на версию 2.0.57.6
Обновление информационной базы выполнено успешно.


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

кстати, предыдущую БД не удалось обновить, подпихивая подряд конфы.. на третьей от конца она забраковала версию платформы, указав, какую надо..

>1. как просто понять можно ли это делать ?

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

редко но бывает... если релизами >> 10 выпусков.

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

переименование металанных - вместо документ.блабла теперь документ.удалитьблабла... соответственно половина модулей библиотеки обновления про это не в курсе - опять упадет

(15) точно. тут главн дело - 1.не лениться, 2.бэкапить

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

предыдущая потребовала 9 релизов.. 5.5 часов потратил.. ничо, выдержал :)

а проверка, по мне - только одна доступная - ОСВ сравнивать после каждого обновления..
больше вариантов не знаю..

(8) Если конфа изменена - обновляешься на тестовой до последнего релиза. Вдумчиво вносишь изменения, тестируешь,  все работают, никто тебя не торопит. Выгружаешь .cf Потом обновляешься на боевой, каждый раз свои изменения вносить не надо. Потом, когда на боевой последни релиз, "сравнить объединить" с твоей cfкой. Все. Времени не намного больше. Не нервничаешь в случае непонятных косяков "а вдруг косяки из-за того, что накатил через 10 релизов".

>Потом обновляешься на боевой

на боевую достаточно "загрузить измененную" полученный на тестовой cf и запустить клиента чтобы процедуры обновления свое отработали

(19) Если через много релизов, то не факт, что в последнем остались все процедуры обновления от старых.

(16) не совсем понял, для чего так делали? 1с же сама выделяет жирным шрифтом максимальный подходящий релиз для скачивания/установки

(20) ещё не видел в БП, чтобы в модуле обновления релиза конфигурации что-то вытерли 1сники. Все процедуры сохраняются.
А метаданные есть с удалением в одном из релизов, но благо, что в обработке обновления они не участвуют, поэтому прыжок происходит без проблем.

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

(21) выделяет, если он уже находится в template.
а я говорил о таблице релизов на сайте 1С

(23) Был Реквизит1 , стал Реквизит2(Р1 удалили), затем Реквизит3(Р2 удалили). Ну собрал я обработки копи-пастом. Ну как, как из Р1 данные в Р3 попадут, если на конфу с Р1 накатить конфу с Р3 сразу? Нет такой обработки обновления, которая одновременно знает и о Р1 и о Р3.