не завершается обновление БП 3.0 #799127

Добрый день, подскажите где в БП 3.0 надо за комментировать строчки чтоб вообще не происходило штатное обновление весь вечер ищу

Общий молуль "ОбновлениеИнформационнойБазы", вызывается откуда-то из модуля обычного / управляемого приложения

Общий модуль "ОбновлениеИнформационнойБазы" это я нашел но там очень запутанные вызовы что то комментируешь начинает не работать другое

Сколько платят за решение?

ОФФ: Убил.

А что это вообще такое - штатное обновление? Обычно штатное обновление это запуск конфигуратора и обновление конфигурации. При чем тут БП3?

Ну, будем надеяться, что он четырехпалубный и сразу не сбежит (: Ъ. Это БСП + hta

обновился с 34 релиза на 50.18 и кокето фоновое задание не хочет до конца проходить, не хзочу разбираться в целом все работает и пусть себе трудиться но при каждом запуске появляется окошко типа идет прогресс обновления вот его я и хочу отключить

Дык а чего там комментировать то я не пойму? Оно что само по себе работает или как? Запустил - работает. Не запустил - не работает.

Ну так отключи ненужные фоновые и регламентные задания, при чем тут обновление?

как бэ вроде есть обязательные релизы, через которые не рекомендуется перепрыгивать. откатись на начальное состояние и воспользуйся Обновлятором - он сам сделает все что надо (место на диске только обеспечь)

Насколько я помню БСП это окошко показывается только администратору данных. Все остальные получают или отлуп при старте сеанса, если обработчик требует монопольного доступа, или работают, ничего не замечая. Ты там кем, менеджером?

Константы.СведенияОбОбновленииИБ там хранится список обработчиков обновления Нужно извлечь из хранилища дерево, найти ИмяОбработчика такое-то, удалить и запаковать дерево обратно.

не вариант откатыватся большая база обновляется 8 часов а за константу спасибо поищу

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

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

Понял. Согласен, это может помочь. Для этого только нужно не забыть поставить в свойствах базы галку "Искать обновления в лоб, а не по ключ. релизам". По умолчанию она снята.

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

>> кокето фоновое задание не хочет до конца проходить, не хзочу разбираться А и не надо разбираться. Оно тебе мешает? Если база сильно большая, может довольно долго отрабатывать. Ну и пусть себе работает. А вот если что-то не доделается критичное, кто ответит за кривые данные? Или следующая твоя ветка на мисте будет типа "Плохая 1С криво обновила мне данные! Что делать?!?!?". Если сильно неймется либо поставь приоритет выполнения обновления вместо работы пользователей, либо зайди в консоль регламентных заданий и вручную поставь там для обновления расписание с более частым перезапуском.

А "в лоб" это когда накатываем последовательно все доступные на сайте 1С обновления - подбираем после каждой итерации "минимально" свежий из доступных.

Проверь в конфигураторе: Сервис - Параметры - Запуск 1С:Предприятия - ПараметрЗапуска, может, там ключ стоит

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

+ Или автор все-таки перепрыгивал и накатывал обновление через финальный cf?

+ А, ну да, автор пишет "обновился с 34 на 50", ясно

Тогда зачем все же в Обновляторе придуман поиск следующего минимально свежего релиза? :)

В каких случаях недостаточно поиска максимально свежего?

возможность обновляться "в лоб" (то есть по всем промежуточным релизам) имеет смысл, когда есть проблемы с выполнением обработчиков обновлений. 1С, ведь не выпускает, например, сразу после 34 - 50 релиз. Между ними куча релизов и почти для каждого обновления пишутся свои обработчики, которые запускаются в режиме пользователя (или внешнего соединения) и выполняют манипуляции над данными базы (после их реструктуризации данных, ведь конфигурация изменилась). И вот есть мнение, что самый безопасный способ (наименее глючный) - это обновляться (то есть обновлять конфигурацию, делать реструктуризацию БД, выполнять обработчики) именно в том порядке как выходили обновления. Это дольше чем по ключевым. Но при перескакивании сразу через несколько обновления (например, по ключевым) не все нюансы могли быть учтены разработчиками и вполне вероятно зависание одного из обработчиков.

тут проблема в другом. Для 34 релиза должна быть платформа например 8.3.4, а для 50 - 8.3.8. Только реальный самоубийца может запускать это всё на одной платформе, да еще норовят на 8.3.10.

Благодарю за ответ

На более свежей надо запускать. Обновляешься до релиза X - убедись что используешь платформу рекомендованную для этого релиза.

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

Как правило никаких проблем не возникает при использовании последнего релиза платформы. Прогонял типовые с первой до текущего момента ради интереса.