(8.3) за и против обновления "через несколько релизов" путём загрузки cf #808142

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

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

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

Кто говорит?

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

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

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

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

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

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

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

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

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

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

Вот мне тоже похрен

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

+100

"А потом в релизе Х, ребятки и вовсе удалят реквизит Удалить_Реквизит1" Это не Пример, а страшилка. Все удаленные болтаются по паре лет в конфигурации на поддержке. А потом останутся в Основной конфигурации уже снятыми с поддержки как свои собственные.

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

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

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

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

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

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

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

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

"ну например, с ут 11.1 на Ут 11.3. Конфы практически одинаковые" В голос поржал, спасибо

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

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

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

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

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

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

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

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

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

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

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

пример релиза приведи

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

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

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

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

Ты что-то напутал

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

+

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

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

Типовые

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

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

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

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

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

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

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

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

зачем?

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

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

смысл ?

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

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

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