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

(0)Да зачем эт надо то?

(0) Кто говорит?

(0) основное, что обработка устаревает. Например, она написана для 8.3.1, а выполняется на 8.3.10. И также названия реквизитов, справочников и регистров отслеживают они? Допустим справочник назывался в обработке ВидыАлкогольнойПродукции, а теперь называется УдалитьВидыАлкогольнойПродукции. Обработка не запустится.

(0) Вы тоже можете так говорить!

(0) (на мотив Слепакова) Че будет если нет?

Это как русская рулетка. Может пройдет без проблем, а может и с проблемами.

Надо тестить.

(0) сталкивался на двух конфигурациях (УНФ и ТСЖ), что лучше всего после каждого обновления на релиз запускать в режиме Предприятие, т.к. могут поднапакостить пресловутые обработки обновления

врут. Этот механизм был во времена 7.7 и в 8-ке не менялся. Я бухию с 2006 года обновляю через пропуски с помощью cf - проблемы не испытываю

(0) только не забудь конфу поставщика обновить

В типовых от 1с обычно проблем нет. С отраслевыми не знаю.

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

(8) В шапке ни слова про конфу, следовательно речь идет о сферической конфигурации в вакууме.

(8) Вот мне тоже похрен

(0) кто-нибудь может объяснить зачем это делать, кроме как из-за лени? А потом мучиться и переделывать разве легче и быстрее?

Я б таких обновляторов и близко к базе не подпускал

(14)
Потому что обновление занимат от недели до месяца.

Судя по всему - вы с такими базами еще не сталкивались.
Все впереди

То обновляют на старых платформах, то сразу на последний релиз скачут, а потом "спасите тут какие-то ошибки".
Извините, накипело.

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

(16) одна реструктуризация идет неделю?
Ну это точно не проблема обновления. Может прежде чем обновлять это сначала решить?

(0) я против шагать через релизы.
Обновляться надо через cfu и каждый раз запускать предприятие и давать ей обработать данные.

(19) ну например, с ут 11.1 на Ут 11.3. Конфы практически одинаковые, а между ниму 80 релизов. Как вы поступите?

хотя мой франч куячит cf-ками

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

(0) Нет не работает.
Обновляли ерп с 2.1 на 2.2 там последовательно релиза 3-4 надо было. делали эксперимент 1 пропускали, выяснили одну из причин - в том релизе который пропустили есть функция в модуле менеджера, а в след ее уже нет и задания с пред релиза выдавали ошибку. Это как пример.

(0) Можно, если говорим про типовые или созданные на их основе.

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

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

(14) Угу, база не обновлялась с 2012 года, то есть пять лет. С релиза 1.17.х до 2.10.х. Это 12 промежуточных с глобальным переходом с ред.1 на ред.2. Доработок за пять лет наделали - конфа перелопачна так, что создатели не узнают. Переносить все в каждый из релизов - это недели две как минимум на один релиз. Надо было полгода заниматься обновлением? В итоге скачок через 12 релизов был сделан за три недели, уже полгода сидят на последнем релизе и радуются. А чтобы ошибок не было надо просто голову иметь.

(20) В типовых фирма 1с так не делает, она сначала накатывает последний релиз, а потом уже запускает режим предприятия. Наверное в 1С дураки сидят, раз заложили такой механизм

(21) 11.1 и 11.3 - одинаковые? Хорошая шутка, особенно оценят те, кто много изменений внес.

Пример.

Есть Справочник1 с реквизитом Реквизит1.
В какой-то момент крутые ребята из 1с подумали что реквизит этот больше не нужен и обозвали его Удалить_Реквизит1. А данные из него перельются в новенький Реквизит2 обработчиком, который запустится после обновления.
И все будет ок, ведь мы обновляемся с cfu
А потом в релизе Х, ребятки и вовсе удалят реквизит Удалить_Реквизит1

Накатив cf, мы гарантированно потеряли данные: Реквизит2 пустой, а реквизит Удалить_Реквизит1 удален.

(29) +100

(29) "А потом в релизе Х, ребятки и вовсе удалят реквизит Удалить_Реквизит1"
Это не Пример, а страшилка.

Все удаленные болтаются по паре лет в конфигурации на поддержке. А потом останутся в Основной конфигурации уже снятыми с поддержки как свои собственные.

(29) ну это самый популярный пример, да, но вроде как умный обработчик даже при накате .cf произведет все нужные обработки, откопирует удаленный реквизит и т.д.
не?

(21) Если УТ 11.1  даже с 11.1.4 до 11.1.10  прыжком не обновлялось,  ибо уникальность записей регистров нарушалась. Куда ему до 11.3

ЗУПы очень критичны к прыжкам....

В пределах одной подредакции,т.е. 11.1 обновлем до последнего релиза 11.1, цфу-шкой переходим на новую версию 11.2 и т.д. Хотя конкретно с УТ 11 была трабла, когда ввели валюту управленческого учета и если ее не заполнить, то обновление не проходило. А так проблем обычно не возникает.

(33) я как раз после 11.1.10 делал

Если cf-кой обновлять, то релиз всё равно останется старый, хотя конфа будет считаться новой.

(37)
на свежих платформах вроде норм
поправьте если ошибаюсь

(38) да и не на свежих. С релизом нормально всё

(21) "ну например, с ут 11.1 на Ут 11.3. Конфы практически одинаковые"

В голос поржал, спасибо

(0) почти всегда cf обновляю, один раз только с отраслевой crm словил проблем

(38) Вы обновляете через поддержку или сравнение?

(42) через поддержку конечно. Какое еще сравнение?

(40) по большому счету что поменялось в структуре данных? Кроме упаковок-единиц измерения?

(43) А зачем тогда прыгать? если типовая то пусть по воздуху обновляется.

(29) Страшилка.
Еще раз.
Обработка заполнения этого реквизита никуда не делась.
Выругается на ошибку и все.

+46 Ну с редакции на редакцию, я бы только обновлял через промежуточный.

(46) А если БСП изменилось? Как тогда конфа обновляться будет?

(34) Если только ранние 2.5. В 3.х вообще автообновление как в бухии.

(46) Ты что-то не понял: вся соль риска в том, что после такого однократного обновления конфигурации БД в ней не будет реквизита, из которого нужно брать данные в обработчике

(0) Пределах подверсии -- обновляй

(50) пример релиза приведи

(46) Могут данные потеряться, могут данные сохраниться. Мне лично эта лотерея нафиг не нужна.

(0) Почему не следует обновляться через несколько релизов с примером описано здесь: http://www.kaminsoft.ru/technical-questions.html?limit=0#p432

Кто хочет получить реальный пример: может взять релиз типовой конфигурации, в которой используется одна редакция БСП (например 2.1), и обновить его на релиз типовой где используется редакция БСП на две редакции выше и более (например 2.3 или 2.4).

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

(53) Типовые от 1с разрабатываются в предположении возможности кумулятивного обновления. Не зря там в каждой последующей версии сохраняются процедуры обновления со всех предыдущих. Баги возможны, но точно так же они возможны и в последовательных апдейтах. Встречались деструктивные ошибки в процедуре обновления, которые были исправлены в следующих релизах обновлений - в этом случае кумулятивное обновление "обойдет" грабли.

(52) Ты что-то напутал

(55) плюсую

(53) Типовые от 1с разрабатываются в предположении возможности кумулятивного обновления только в фантазиях ленивых обновляторов. То есть в 1С идиоты сидят, расписывая с какого релиза на какой можно прыгнуть, а ты их умнее?

(0) 8 лет на форуме а до сих пор в сказки верите?

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

а голосовалка то где? -)

(26) как раз для таких обновлений пишутся ТЗ и там оценивается возможность разных вариантов переноса данных, а не просто так с лёта на авось накатили самую последнюю cf и сидят смотрят где что вылезет.

(57)Он просит пример релиза, пример релиза в (54)
(52)То, что тебе нужно находится по ссылке из (54)

(63) т.е. это пишут про типовую БП ?

Мое скромное мнение по поводу рекомендации легковерным по обновлению с пропуском релизов.. Если-б, как мне однажды тут возразили, все последующие обновлялки включают все предыдущие, то.. ИМХО.. последнее из доступных было-б раздуто до нескольких гигабайтов.
А обновленьица-то, извините, все ровненькие, как на подбор.
Так чта.. если лень одномоментная обуяла программиста, пусть обновляется на последнюю, и имеет в результате последние слова из поста Снеговика (62)

думаю пятница удастся.

(54) Еще раз.
По ссылке, если обновить пропустив релизы, выйдет ошибка.
Т.к. реквизита уже не будет.

Про БСП смену редакции также. В этом случае ошибка идет, откатываемся назад и обновляем как надо.

(64)Не знай, мне казалось там про ЕРП, а ты как думаешь?

Голосовалка возникла.. Это - пять.

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

Список со ссылками на предыдущие обновления составляли не дураки..
Неча считать себя умнее фирмы 1с..

(67) >>> откатываемся назад и обновляем как надо.

а теперь представь, что у тебя новый релиз требовал новый сервер CЛК и у тебя к нему едет не одна а 5 разных отраслевых конф, и тогда тебе придется из-за одной конфы откатывать назад
1. сервер СЛК
2. все отраслевые конфы


ps
привыкайте делать правильно даже если сейчас это и не вызывает проблем...

(58)  "расписывая с какого релиза на какой можно прыгнуть"
Это означает только то, что обновление включает в себя диффы с соответствующих релизов, и ничего больше. Нигде нет запрета на обновление из cf.
(69) А работа пусть стоит? Или ночевать оставаться в нерабочее время? Подготовить cf спокойненько, и потом его накатить на все n баз за кратчайшее время монопольного доступа.

(65)  "Если-б, как мне однажды тут возразили, все последующие обновлялки включают все предыдущие, то.. ИМХО.. последнее из доступных было-б раздуто до нескольких гигабайтов. "
Речь о модуле с процедурами обновления ИБ. Они действительно включают все предыдущие. А с метаданными такого не требуется - они просто добавляются. Ситуацию, когда метаданные в обновлении удалялись, я не припомню для типовой БП или ЗУП, по крайней мере когда это касается используемых объектов, а не ошибочно добавленных одним релизом и не заполненных.

(71) А работа - пусть стоит.  Да.
Если бухи выкатывают очередную хотелку из-под законодательства, пусть понимают правильно: обновление требует времени.
Да, и ИТС"ов тоже требует.. Это на случай, если ГБуха жадность к чужим деньгам обуяла.

"через нескока релизов"
Вот как пишут, так и обновляют.

Если сотрудник франча или фрилансер хочет заработать побольше часов - он обновляет последовательно. Это совершенно логично.

конфы и версий таки нет? тогда все ок будет!

(75) колесо крутится - монетка мутится.

Содержу базу накопительных обновлений, из нее делаю файл поставки, с которого обновляю хоть полуторогодовалые базы. Проблем не было пока ни разу(тьфу-тьфу).

(69) причем тут фирма 1с? Что-то вы гоните. Фирма 1с делает обновления на все случаи жизни, закладывается на всё. А в реальности используются далеко не все возможности, они не нужны. Поэтому программист местный принимает решения, через какие релизы прыгать.

Например, поменяли структуру регистров НДС и книгу продаж, поэтому лучшие умы фирмы 1с выпустили отдельный релиз. Но если у нас упрощенная система, Нету НДС, регистры все эти пустые, начихать на их структуру. В этом случае можно спокойно перепрыгнуть через этот релиз. Невзирая на авторитет фирмы 1с в составлении списка.

+(78)

(70) Я про типовые.

Про отраслевые, да можно налететь на защиту.
Но я всегда пробегаю по промежуточным релизам, что бы посмотреть требования.

p.s. И да я по возможности стараюсь обновлять последовательно. Но для измененных конф, это не всегда подходит по времени.

(78)Доработанные базы имеется ввиду?

(82) Типовые

(68) я общался с разрабами (2-3 года назад) типовой БП -- они сказали, что таких фокусов, описанных в 54, быть не может

(78) но не через "загрузить цф" же

(79) А я разве возражаю? Просто выразил своё мнение, принимать/не принимать его - каждый решает сам.

Хочется переделывать работу - так в добрый путь!..

ЗЫ. в пятницу можно и байку рассказать, тем паче, что тема немножко легковесная.
В книге "Алые паруса" есть разговор двух персонажей, один другому объясняет путь из одного пункта в другой:
1 - Идешь прямо, до ручья, там будет мосток..
2 - .. Ага, я понял: перехожу через мосток..
1 - Ну, да.. можешь переходить, если любишь возвращаться..

(81) типовые по любому надо обновлять не реже 1 раз в квартал, по этому там обычно 2...3 скачка, что вполне нормально...

(84) 2-3 года назад эти разрабы еще котиков не вставляли в БП, а теперь уже два разных котика есть!

(86) наоборот, хочется сократить свою работу. Это напрямую программиста касается. Сколько он потратит своего личного времени на это обновление. Может час обновлять, а может по вашему методу целый день сидеть.

(88) котика очень хотел Фогель )

(89) Когда ГБушку достала налоговая, я накатывал на БП последовательные обновления в количестве 8 штук, в течение 5 часов.

(87) зачем?

(92) Чтобы топать в ногу со временем :)

(85) Я не камикадзе. Через "обновить...".

(93) смысл ?

На КА 1.1 всегда так делал, субъективно осложнений не возникало

(95) Друже, наше Налоговое - самое гибкое Законодательство в Мире.
Потому и возникают обновления, и вовсе не по причине, что кто-то дозвонился по горячей линии до фирмы 1с..
ЗЫ. я бросил эти бесполезные попытки лет 12-15 назад.

(91) ну это хорошо если почасовая оплата. А если клиент на абонентке? Это ваши выброшенные 5 часов из жизни. Например, читаете новое в этих релизах. Изменился НДС, вам это не нужно, изменилась форма ФСС, тоже нахрен не упало, это вы вообще в ЗУП ведете, а не в бухгалтерии. Поэтому просто берете последнюю cf-ку и накатываете. У вас на это уходит полчаса. А не 5 часов.

и бухи, они заразы умные теперь, они про вас будут говорить: приехал прог, просидел 5 часов, ничего не сделал и уехал.

(90) Это мне, увы, мало о чем сказало. Это усатый из 1С?

А не, тот-то Нуралиев (волговод)

(98) Если клиент на абонентке и ты обновляешь за фикс. стоимость, то или смирись, или ССЗБ :)

(98) Ну, так можно сделать их ещё умнее, объяснив механизм внесения изменений..
Умнеть они будут с удовольствием.

Лично я понимаю последовательное обновление как возможность менять структуру (убирать старые таблицы в основном) базы для разработчиков.  Но с другой стороны если обработка обновления не ругалась... значит все нормально?!

(103) Ну, да.. Нормально.. Если бухи через пару-тройку дней не стали ругаться..

(88) Кстати да, котики. А первый был намного лучше, сейчас какой-то блевотный анимэ

(83)Для типовых есть обновлятор же :)

(78) > Содержу базу накопительных обновлений, из нее делаю файл поставки

т.е. конфы поставщиков полностью типовые и кнопка включить возможность изменения присутствует ?


(94) > Я не камикадзе. Через "обновить...".

как ты не через обновить -- обновишь конфу поставщика?

(105) интересно, пойду обновлю ради нового котика)

(104) Если не было проблем со структурой базы... То что может быть? Мне интересно, кто спец подскажите тогда.

+(109) Так как я не понимаю полностью ситуацию сам всегда обновляю последовательно. Но было бы неплохо иногда на последний...

(0) нужна конфа поставщика текущей версии и той версии на которую надо обновлять.Тогда можно сделать  поставку конфигурации, после обновления все обработки обновления базы запускаются последовательно пропущенным релизам, если конфа не сильно изменена вполне возможно так обновлять. Просто накатывать  cf ОЧЕНЬ не советую

(111) > Просто накатывать  cf ОЧЕНЬ не советую



конкретные примеры приведи

(0)Много раз так делал, ни разу не напоролся перед обновлением делай копию и все, потом все что угодно починить восстановить можно. Риск только 1 если в одном релизе переименуют реквизит в УдалитьРеквизит а в след перемещение его значение в новый объект или реквизит, когда перескочишь новые объекты будут не заполнены, но такую ситуацию ни разу не получил. А сидеть 30 релизов последовательно накатывать на медленном сервере- мартышкин труд.

(107) Шесть лет - полет нормальный.

Субьективно: обновлял так БП 3.0, УТ 10.3 и УПП 1.3 в пределах одной редакции, разумеется. Причем скачки были порой на 10 релизов(ну или 4-5 ключевых). Проблем не возникало. Наоборот: как-то раз переживал, что пропустил релиз БП 3.0, а на следующий день релиз отозван и на страничке обработка с инструкцией по восстановлению данных

(107) Пустая база с ИТС, и она постоянно обновляется. А когда тебе нужно пойти обновить, делаешь файл поставки, и вперед. Даже обратно на поддержку измененную можно поставить. Это тот же файл обновлений, только список разрешений шире.

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

(116) много времени смотрю свободного )

(117) так и типовые обноляешь ?

(118) Откуда такие выводы?)) Сейчас у меня только нужные мне базы. Время как раз экономится.
(117) Я про типовые и пишу.

(120) А по нетиповым: базу разработчика обновляешь упомянутым мной файлом,  и потом делаешь поставку. Ой... Что ж, я! Вас учить буду что ли?!... =)))

(116) Наверное не файл поставки делается? а выгружается cf? для обновления на несколько релизов
P.S. Если для типовых делается файл поставки это уже не типовые...

ЗЫ. Немного в офф, правда.. Что за "котики" - нельзя-ли скрин с ними выложить?.. а то пребываю в неведении, зазорно :)
Все знают, а я - нет :)

(123) В какой-то винде (не помню) был помощник. Вот, типа того. Только (почему-то) пользователей раздражает :(

(124) Ааа, ну ясно :)

(120) > Я про типовые и пишу.

ты знаешь в типовых есть механизм автообновление конфигурации?

(126) Обижаешь?))
Не все клиенты об этом знают. Да и подписка на ИТС нужна. А когда они сидели, сидели, а тут вдруг: ой, ну давайте - подписались и обновились.

(123)
Правильный котик 1С https://cs9.pikabu.ru/post_img/2016/11/17/6/1479370908141023456.jpg

Котик "ой всё"
https://cs8.pikabu.ru/images/big_size_comm/2016-05_6/14646073111713754.jpg

еще коты но очень хреновые

https://habrastorage.org/files/239/0a1/8ab/2390a18abad34fb7a1504fe80a1aa40b.png

(123) Старый котик: http://radikal.ru/lfp/s019.radikal.ru/i618/1605/6c/fe39cee0630d.gif/htm

Новый котик в 29 посте: https://forum.infostart.ru/forum8/topic151917/
Старый котик:

Я дал ссылки на анимированных!

(122) Действия: Конфигурация - Поставка конфигурации - Комплект поставки - Создать файлы комплекта.  В результате получаешь cf, но конфигурации поставщика.
Попробуйте сделать выгрузку в cf и создать файлы поставки.
У меня в КА выгрузка 475 Мб, а поставка 265 Мб. Из одной и той же базы.

ок, вот анимированный нынешний кот

https://forum.infostart.ru/upload/forum/upload/9f0/9f04010c30371f912ec44cb977d7f09d

(128) (130) (133) Спасибо! :)

зависит от конкретного случая. с УТ 10.3 - обновился недавно с 10.3.17 до 10.3.45, без особых проблем. с новоделами обычно лучше обновляться последовательно или скакать максимум пару релизов, слишком усложнилось все в БСП.

(127) я всем поставил своим клиентам эту функцию

(136) А с неба клиенты не падают?))

(132) зачем так сложно ?

конфигурация -> поддержка -> настройка поддержки
внизу есть кнопка Сохранить в файл

достоверно точно можно получить cf от 1с, если в правом вернем углу есть кнопка Включить возможность изменения

(137) да, не успеваю

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

Ответ от знатоков: здесь все смешалось в одну кашу. Механизм загрузки cf здесь не причем - это первое. Второе - то, про что ты пишешь - обеспечивает (в какой-то мере) одна подсистема из БСП. Суть ее работы сводится к тому, что при запуске, идет проверка версии конфигурации. И если она изменилась, то последовательно запускаются обработчики обновления данных от номера версии, которая была, до номера обновленной версии конфигурации. Вот этот механизм, про который ты "краем уха" слыхал. Как уже отмечали выше, это не позволит взять УТ 11.1 и обновить ее до УТ 11.4 через одно обновление :) Более того, даже просто чтобы физически такое прокрутить - нужные некие дополнительные телодвижения.

(0)
Вопрос написан так:
А эти ягоды кушать можно?

PS О какой конфигурации речь?

(140) не хилые, да не сильно много.
надо взять таблицу релизов от и до последнего.
вывести колонку с изменением редакции БСП.
вывести колонку с релизами, где удаляют объекты метаданных.
это не так часто происходит, если это не ут11.1 или 2.
и спокойно прыгать по этим 2м колонкам.

(141) вопрос написан так, как написан, какие ягоды-грибы, товарищ?)
речь о любой конфигурации имеющей больше одного релиза
сам обычно обновляюсь последовательно, однако были исключения в виде пропуска 5-10 релизов, и всё норм было
косяк был только с сельхозкой - отказалась прыгать через несколько

(142) приведи конкректные релизы 11.2, где удалили данные

(143)

Ну как бы вам ответить. Вот БП поддерживает то, о чем пишется, а например УНФ не поддерживается...

Вам как ответить в таком случае: можно или нельзя?

А про ягоды, это классика. Просвещайся:
https://www.youtube.com/watch?v=gyQw6Tt35Lc

Обновляйте CF-ками дальше, после таких “обновляторах” калыма только больше)
А так да, плюсану к (24) и (29)

(146) как работает пользовательское обновление (из режима предприятия) не знаешь ?

(145) а как выясняете какая конфа поддерживает, какая нет?
опытным путем?

(146) Ну если так, то и накатывать обновления надо на именно тех релизах платформы, для которых они выходили. Для неленивых.

Не проще ли просто взять и обновить последовательно? Вашего времени это почти не занимает.

(148)

Нет, просто знаю механику БСП и где смотреть... но этого в вопросе не написано же ))))

+(150)При последовательном обновлении проблемы то возникают, а через релиз вообще туши свет, а главное как быть уверенным что все прошло норм? Сидеть потом пару недель перепроверять?

(151)
а, ну ну)

(150)

В этом случае товарищи вынуждены тащит свои поделки через многократное "объединить/сравнить и что бы не затереть"... а иногда это крайне сложно, особенно если подсистемы переписаны глобально.

Вот и "экономят"... но "скупой платит дважды" еще не кто не отменял )))

напишу как работает штатный механизм автобновления конфы:

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

после этого пакетно запускается конфигуратор, в который последовательно загружаются cfu, сохраняя после каждой загрузки БД (режим предприятия не включается)

после того, как все обновления загружены -- запускается (один раз) уже режим предпрития, в котором идёт последовательно обновление ИБ по тем релизам, которые загружены в базу

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

+(156)Зачем тогда разбирают как работает типовой механизм обновления? Он тут просто не катит.

(155) кстати, а это они не от хорошей жизни запускают выполнение обработчиков в самом конце

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

ну и да - оставляя выполнение обработчиков в конце, ИМХО они расчитывают, что пользователь будет обновляться часто, а не раз в полгода

(157)

Я не знаю, могу лишь предположить сценарий работы таких "специалистов":

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

Наверное так...

(155) А от куда такая информация, не поделитесь?

(160) Из конфигуратора, вестимо.

(160) штатная обработка "Поиск и установка обновлений" в типовых создает во временной папки служебные файлы для обновления в режиме пользователя. Среди них есть hta файл - это главная программа, и вот из неё уже запускаются файлы на JavaScript (они в этом же временном каталоге). Именно в этих js файлах и идёт накатывание обновлений в пакетном режиме. Если их почитать (там кода немного), то становится понятен весь алгоритм стандартного обновления в режиме пользователя.

Сама обработка скачивает все необходимые обновления и формирует текст этих js файлов. А уже на JavaScript прокручивается весь цикл обновления за счёт пакетных вызовов конфигуратор.

(160) А конкретнее?
Я вот что увидел, при первичном рассмотрении.
Например УТ 11.3 есть модуль "ОбновлениеИнформационнойБазыУТ", в ктором находятся обработчики, которые запускаются при обновлении. Дело в том что там список не дополняется новыми обработками от релиза к релизу, а формируется новым списком. Если взять два релиза 11.3.3.231 и обновление 11.3.4.93, то в сравнении этих модулей есть как удаленные так и добавленные и номера у них разные. Получается если делается в таком режиме как описал (155) то не обновится правильно, так как (24) (29).

(163) Владимир спасибо за пояснения!

Я года четыре обновлял ЗУП 2.5 для России и ЗУПы для Белоруссии и Казахстана сравнением-объединением. Готовишь последний актуальный cf-ник и всё нормуль.

(155) Чтобы ты понимал, предполагается что автоматическое обновление конфы в режиме 1С Предприятия будет выполняться каждый релиз, сама платформа вываливает сообщение о том, что доступна новая версия, как только она выходит. И просит обновиться. Т.е. предполагается что каждое обновление будут накатывать последовательно, даже в режиме обновления из Предприятия.

Ежели нифойхуа не обновлять а потом попробовать обновится в режиме 1С Предприятия сразу 100500 релизов, то можешь бороднуться потом в конце на обработчиках обновлениях данных.

О чем и написали в (24) и (29)

(167) При таких раскладах полезности от автоматического обновления мало, те же **** только вид сбоку, как при ручном обновлении на каждый релиз.

(167) приведи мне примеры фактов релизов типовых 1с где проблема в рамках под редакции ....

Вчера вот вечером занималась обновлением УТ 11.2 на УТ 11.4 - на 14 промежуточных релизов (это с перепрыгиванием на допустимые) одним файлом. Удалены только некоторые модули.

(170) надо обновлять  так

последний cf 11.2
последний cf 11.3
последний cf 11.4

(170) То есть 14 раз обновилась база и 14 раз была запущена в пользовательском режиме?

Или взяли выгрузили конфу 11.2, догнали ее (14 раз обновили) до 11.4. Потом взяли конфу обновленную до 11.4 и сравнением объединением объединили с рабочей 11.2?

(173) пока не закончила. Перед этим доработки в расширение перетаскивала. Может на выходных завершу. Осталось принять изменения.

Смысл в таком действии , если только реально экстренная ситуация.

Сейчас типовые стали слишком замороченные. Запросто может что то не так пойти.

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

(174) но алгоритм какой из двух описанных в (173) применяете?

(176) База с более старого релиза 11.1 постепенно догонялась до 11.4.
Боже, где смайлики?! Механизм описан выше.

(175) благодаря вам у меня всё больше и больше клиентов )

(177) Так у вас обычный рекомендованный способ обновления))))))))

(178) Нам не жалко. Хороший спец всегда в цене

Как у меня бомбит от тех кто ленится и льёт ЦФ, забывают постоянно конфу поставщика обновить, потом половина регламентных в незавершенном виде от перехода висят, конвертации отваливаются, новые измерения для старых движений не заполнены и т.п.

Что ж вы всё из*вер*нуться хотите. Работай нормально.

(181) > кто ленится и льёт ЦФ, забывают постоянно конфу поставщика обновить

все вменяемые люди обновляют конфигурацию через обновление конфигурации поставщика

(181) только с точки зрения теории
(182) а как это? "через обновление конфигурации поставщика"

(182) согласен...
(183) Это как по инструкции 1С =)

При накатывании обновления видно же что изменилось и есть текст с изменениями, критических изменений нет - накатывай. Сомневаешься, то обновляй по порядку. Главное уверенность в  проделанной работе.

(183) >> а как это? "через обновление конфигурации поставщика"
это так же как в (181), только наоборот.

+(185) выбор...

(184) где посмотреть на эту инструкцию?
как обновить конфигурацию поставщика я знаю, вопрос только в том, что имелось ввиду "через обновление конфигурации поставщика". Я такого способа не знаю, поэтому и спрашиваю.

(188)
конфигурация -> поддержка -> Обновить конфигурацию -- так обновится конфа поставщика

а через
Конфигурация -> сравнить\объединить -- не обновишь конфу поставщика

(189) zak555 я понял, спасибо.

(169) В рамках под редакции пример не приведу, но люди выше уже написали что с ЗУПом бывают траблы и в рамках под редакции.

Ну и в сабже ничего нет про обновление в рамках под редакции)
В сабже обновление между релизами.

(0)Так нельзя.

(191) пример релизов -- я готов проверить

поэтому читаем все те же (24) и (29)
и да , забыл проголосовать

(62) Был бы клиент, требовал бы техзадание и кучу подписей в том, что после тестирования клиент никаких претензий иметь не будет ) А тут - устроился на работу в компанию где с базой вот такая фигня была, пришлось делать вот это всё. На самом деле так обновляться можно. Но нужна весьма кропотливая подготовка нового cf, анализ типовых обработок обновления и, возможно, добавление своих. Конечно же после всего еще и обновление каждого ключевого релиза через cfu, снимая все галки - чтобы конфа поставщика тоже была обновлена. Ну и реестр всех доработок, чтобы в последующем меньше париться с обновлениями.

(196) понятно откуда ветка родилась "Конечно же после всего еще и обновление каждого ключевого релиза через cfu, снимая все галки - чтобы конфа поставщика тоже была обновлена." вот тут косяк