есть БП базовая 2.0.32.6
нужно обновить до последней 2.0.63.6

как правильно делается? неужто ставить все 31  обновления по очереди?

я бы попробовал обновить с cf файла последнего релиза и посмотреть, есть ли проблемы

(0)  По очереди.

(2) если есть некритические обновления - их можно пропустить...

(3) как ты их определишь?

(0) База типовая. Не составит туда по шагам.

труда*

(4) берём последную 2.0.63.6 - смотрим спосок версий которые можно обновить, все кроме самой старой - не критические...

(5) а если ещё и фра то принесёт доп. нал

(8) так он и написал что обновлений 31 вместо возможных 70-90

по релизу за обновление. Я почему-то подумал что есть какая идея сразу скакнуть на последний релиз минуя абсолютно все. А с таким работая во фране я сталкивался.. Проще и правильнее последовательно по релизу. На типовых не более 10-15 минут на релиз. При этом особо не отвлекаясь от других дел.

Обновлял недавно с 34 релиза по 63, последовательно по одному - ушло 15 часов, база была SQL около 20Гиг. Среднее обновление 10 минут на релиз. Есть два релиза 37 и 40 - делается реструктуризация базы по часу. Ну и в 42 заполнялся новый регистр около 2 часов.

(11) +база не типовая бух.

(11) типовая чтоли?  всего 10 минут на сравнение.

2 месяца назад обновлял базовую БУХ с 2.0.18.1 до 2.0.62.4, выбирал только критические обновления. по времени ушло 10 часов со скачиванием обновлений с сайта.

Обновляй по очереди, больше денег заработаешь )

(13) от компа зависит. Если на сервере всё делается, то реально.

Есть дистрибутив полного обновления, там сразу можно

(17) каким же образом?

Качаешь и ставишь

Насколько я знаю есть дистрибутивы обновления и есть полные дистрибутивы

(10) "На типовых не более 10-15 минут на релиз"
Если после каждого обновления конфигурации НЕ обновлять базу (в пользовательском режиме), то это равнозначно разовому обновлению на последний CF ;)

А с обновлениями в пользовательском режиме в 10-15 минут вряд ли уложишься... ИМХО

(20) при полном через сравнение и объединение?

(22) Я не помню

(23) я всегда обновляю последовательно критические обновления. а через сравнение и объединение никогда не делал. надо попробывать.

Если время критично и база большая, можно просмотреть по обработчикам обновления, где данные переносились из удаляемых реквизитов, и обновлять до того релиза, где эти данные переносятся. Обычно для удаляемых реквизитов 1с ставит префикс "Удалить<ИмяРеквизита>".

Если со временем проблем нет - обновляй последовательно и не мучайся.

база не одна а штук 10))
одну бы я последовательно обновил но 10 это нанеделю

загрузил cf последней конфигурации.
вроде работает.
что интересно ,при запуске стали выводить список сообщений о последовательном обновлении с одного релиза на другой. то есть в 1с видимо предусмотрено обновление перескоком на последний релиз конфигурации

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

Проблема может быть, если, например, в релизе 2.0.40 изменили структуру регистра адресного классификатора, старый регистр переименовали в "УдалитьАдресныйКлассификатор", и написали в обработчике обновления перенос данных из старого регистра в новый. А в следующем релизе 2.0.41 удалили регистр "УдалитьАдресныйКлассификатор". Тогда при обновлении сразу на 2.0.41 переносить данные в новый регистр будет просто неоткуда - старого классификатора в базе физически не будет.
Насколько я знаю, сейчас 1с избегает подобных изменений структуры в типовых - в последних релизах ни разу не встречался, но в каком-то из очень старых релизов бухгалтерии такое точно было.