Еще раз, пример.
У меня есть база типовой бухгалетрии в которой например у реквизита документа изменен составной тип , вместо стандартного типа СправочникСотрудники добавлен еще СправочникФизЛица, и еще изменен модуль документа например.Так вот, нужно обновить базу на 3 релиза допустим.

1) Я беру рабочую базу (делаю копию естественно) , через Поддержка-Обновить конфигурацию, выбираю файл обновления ТИПОВОЙ cfu для второго релиза.

2) Обновляю базу  но когда выходит вопрос "Обновить конфигурацию базы данных?" отвечаю НЕТ. Заходу в составной тип и добавляю еще тип СправочникФизЛица.

3) Обновляю конфигурацию базы данных и запускаю режим Предприятия чтобы сработала обработка перехода с релиза один на релиз два.

4) Все тоже самое для второго и третьего релиза

5) После обновления третьим релизов, добавляю опять составной тип и добавляю все остальные изменения, в данном примере модуль документа изменяю как был изменен у нас.

5)Обновляю конфигурацию базы данных и запускаю режим Предприятия.

Так вот, можно ли так делать?

Просто мне рассказывали что нужно например создать чистую базу второго релиза, внести туда изменение например добавить наш дополнительный тип СправочникФизЛица ,потом выгрузить базу в cf и уже им обновлять нашу базу, и так видимо для каждого релиза, это же на много дольше получается!?

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

Опять ты по флудить решил? Тебе одной ветки мало v8: Прыжок через несколько версий

(1) 3 ветки.  + 1 на форуме 1С =)

(1) Я там последние постов 10+ уже согласился с тем что нужно обновлять последовательно и спрашиваю как правильно это делать ,а вы мне пишите "Обновляй последовательно и не люби людям мозг, раз так боишься потерять данные" хотя я уже давно говорю про последовательное.

(2) Ну реально же нету ни одного полного ответа. Я понимаю что вы все знаете хорошо всё и разбираетесь в этом но начинающим очень сложно понять все ваши ответы отрывками и т.п. Хорошо прикалываться когда знаешь это. А объяснить нормально ни кто не может.

(2) Я тебе честно скажу - вообще слабо понимаю суть этих всех cf.
Равно как сильно сомневаюсь, что все они ведут проверку наличия в обновляемой базе чего-то ещё, кроме версии.
Поэтому не люби мозг. Возьми типовую конфу. Тупо обнови её последовательно цфками. Сохрани и наложи на свою. Всё!
Получится быстрее и ничего не потеряешь.

(4) * to (0), (3)

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

(0)Вот ты упертый:-)
Эту бы энергию, да в мирных целях

(7) Кто нибудь бы хоть еще по теме отвечал, было бы вообще отлично

50 ответов из них 49 осуждающий какой я дебил и т.п.

Вот я расписал пошагово, вы только скажите это правильно или нет? если нет то как нужно?

(9)А может ты правда дебил?

(9) Паша, давай по-порядку, ок?
1) У тебя есть измененная конфа, которую нужно обновить на три релиза, так?
2) Есть соответственно 3 cf файла обновления.
3) Ты хочешь выяснить, правильно ли будет обновиться так, как ты описал в (0)?
4) Ещё интересно, какие релизы можно перепрыгиать, а какие нет?
5) И под финиш - где найти таблицу обновлений?
Я правильно всё понял?

(12)
1) ДА
2) Есть cfu стандартные типовые
3) Я хочу понять в какой момент мне нужно внести мои изменения всего лишь то!
4) Уже не интересно, я хочу хотя бы понять как правильно обновлять последовательно все релизы.
5) Таблицу в которой указано что нужно перетаскивать в каждый релиз, а что только в последний можно добавить.

(13)дурак или сам стреляется или его убивают.

(14)Ну какой смысл писать что-то не в тему

(15)это мысль насчет подумать.

Ок.
Теперь обрисую суть.
У тебя есть три "урезанных" файла обновления для типовой базы.
В конфигураторе 1С есть два способа обновить конфигурацию.
1) Конфигурация - поддержка - обновить конфигурацию;
2) Конфигурация - сравнить, объединить конфигурацию из файла.
Вторым способом обновиться с "урезанных" файлов напрямую ты не сможешь, ибо вава (да и не даст - скажет, обновляйся первым).
Но ты можешь создать типовую конфигурацию, обновить её последовательно и НЕ ЗАМОРАЧИВЯСЬ на все свои изменения. Запустить её, чтобы там прописалось всё что нужно и т.п.
Вновь зайти в конфигуратор и сохранить конфигурацию в файл (в цф).
Зайти в конфигуратор своей базы и ВТОРЫМ способом обновиться. Поправить всё, что там тебе надо - запустить свою базу.
Так ты точно ничего не потеряешь ни из своих данных, ни из новинок 1Сников.

(17) Ну у нас же получится cfник сразу 3 релиза, и им мы накатим обновление на рабочую базу получится рабочая база сразу прыгнет на 3 релиза, разве нет???

(17) Но это всё я делал только первые пару раз. Ибо лень. В соседнем форуме 1Сников написал тебе, как я это делаю сейчас =)

(18) Да. Но не через файлы обновлений сфу, а через файл конфигурации сф!
Не путай - это разные вещи!

(20)он реально тупой...пусть живет своей жизнью...

(20) я не путаю,я понимаю что это полная конфигурация, а cfu это только изменения, так все равно та же фигня получится. Был реквизит Сотрудник, его переименовали в УдалитьСотрудник обработкой при запуске перенесли все в из Сотрудника, в втором релизе создали реквизит ФизЛицо и перенесли туда обработкой все из УдалитьСотрудник, в третьем релизе удалили реквизит УдалитьСотрудник. Если мы выгрузим cfник 3 релиза там уже не будет реквизита УдалитьСотрудник, и обработка не сможет туда скинуть или забрать от туда что-то.  ???

(22) Так переименуй ручками в своей базе так, как есть в новой!
В режиме сравнения конфигураций он тебе ясно покажет, что идентифицировал, как соответствие, а что - как присутствующий в одной базе и отсутствующий в другой.
К тому же не будет удалять того, что нет в новой, но есть у тебя.
Это так не очевидно, Павел Алексеевич?

(17) В курсе что будет с конфигом поставщика при таком подходе?

(24)Вот и я про тоже, поставщик же полетит... Я и пытаюсь понять как через ПОДДЕРЖКУ правильно обновлять......

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

(26) Обновляю но когда спросит "Обновить конфигурацию базы данных?" отвечаю НЕТ. Заходу в длинну кода меняю ее ,и потом только обновляю конфигурацию базы данных и запускаю в режиме предприятия , да ?

ДА!!!

(26) Вроде просто, можешь вот прям железобетонно аргументировать что это даст результат отличный от 3цфу + цфник со всеми изменениями и только потом обновление конфига БД? Просто если есть совет то значит знаешь и привести аргументы не проблема.

(28) Вот этого ДА , я добивался уже часа 4 , и выслушал кучу троллей. Спасибо огромнейшее!!!

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

(29) Обновлять БД нужно после каждого cfu

(31) Аргументы? Кроме мнения уважаемых гуру конечно.

(24) 1С это та же база данных + логика её обработки.
Вся суть сводится к тому, чтобы отслеживать изменения названий таблиц и её реквизитов.
Релизы не так уж часто меняют их - в основном логику обработки.
Так что не вижу основных проблем отслеживать это самостоятельно.
Про поставщика - приму любые помидоры, но не совсем понял, на кой оно нужно  и с чем это едят? =)

(29) Избежим ситуации в сообщении (22)

(33) Ну если поставщик не той же версии что и база то по сути конфигурация у вас не на поддержке. Сложнее понять какие изменения вносились в ручную и т.п.

(35) Поставщика можно обновить и потом отдельно после обновления на cf

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

(34) Такая ситуация даст о себе знать через синтаксическую ошибку.

(34) Это единственный аргумент?

(38) А вы как предлагаете?

(39) Предлагаю что?

Как обновляться нужно смотреть на сколько сильно поменялась структура метаданных от релиза к релизу
Я сам обновляюсь исключительно на cf.
(38) Да

(41) Последовательно?

Но для "начинающих" советую попробовать обновить и на cfu и на cf
(42) В основном нет... За..пешся последовательно обновлять, геморно это

А на cf вы имете ввиду делать измененый cfник с напиши изменениями , последнего релиза, и накладывать через сравнить\объединить?

нашими*

(38) Вспомнил еще одну вещь, если удаляют какие то метаданные то при обновлении на cf они не удаляются (т.к. галочку поставить не дает)

(44) Я делаю в основном так, и если нужно потом догоняю поддержку когда есть время и удаляю хлам

(41) И можешь привести ситуацию из жизни? Я не представляю каким надо быть тормозом чтобы тянуть что то из удаленного объекта, я вот честно не встречал такой ситуации. Вот ты бы на месте прога ЗАО 1с стал бы такой код писать? Если и имя конфиги и релиз где такое нафигачили в студию вынесешь вообще будет бомба.

(43) нет, времена изменились. Последние 4-5 релизов БП 1С вообще никаких серьезных изменений, в основном регламентированная отчетность. Поэтому обновления через cfu теперь рулят.

(47) Двойная работа вроде как получается. Не?

(43) Обновления - это всегда геморно =)
В ветке автора на соседнем форуме написал самый простой и не пыльный способ:
"звоню в фирму, где брал ИТС, прошу соединить с программистом и слёзно жалуюсь, что у меня их cfu ниразу непрокатывают: выдают ошибку, виснут и вообще творят что хотят по беспределу...
Проникшийся прогер скидывает мне на мыло готовую последнюю типовую конфу, которую я без лишних заморочек и накладываю на свою базу =)"
Ну, и если там что с реквизитами чехорда была - просто скажет, где именно нужно что ручками подправить =)

(50) Нет. СФУ обновляются вразы дольше, чем напрямую через сф.

Ну ладно с Cfu все понятно, тогда вопрос по cf последний, если все же сразу обновлять на cf можно ли как то сразу понять что какая то обработка у меня не сработала и появился какой то косяк, чтобы например откатиться назад и делать через cfu например в таком случае =)

(49) Серьезные изменения в старые времена это что такое? Пример можно? А то все как то на словах у всех и в теории, практика критерий истины :)

(54) Ну обнови один из первых релизов ЗУП на последний cf-ником и посмотри какая каша у тебя получиться =))

(55) А как это отследить можно? Чтобы сразу понять что лучше все же cfu в данном случае.

(54) ну  то, чо ТС предлагает.

(57) То есть нарваться на такую ситуацию в реальности сейчас маленькая вероятность?

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

(55) Ты случай прям приведи из практики с релизом желательно а не отмызвайся :)

(55) Не помню я такого случая! Я логично описал как избежать того что написано в сообщении (22)

(57) То что ТС предлагает и чего опасается вылетит если что у него с синтаксической ошибкой, разве нет?

(59) А можно пошагово про цфу+ цф , а то не могу сообразить...

(62) Выходит то что я вобще выдумал мало вероятную ситуацию, а лучше все делать cfником?

(53) Можно. Просматривай внимательно изменения, которые предлагает тебе релиз. Если есть родные объекты конфы, отсутствующие в табличке справа - переименуй их по семантике. Всё.

(61) Вобщем ты не знаешь но просто предполагаешь. Ладно тогда не буду тебя мучать и требовать аргументов.

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

Ластик , спасибо за подробные ответы! Ну это все понятно про дважды измененные и т.п. А можно поподробней про цфу+ цф , а то не могу сообразить что вы имеете ввиду

v8: Обновить ЗУП 2.5.33.4 до 2.5.45.2. Есть ли подвох ?

(68) Получается уже больше года как нету релизов которые нельзя пропускать , тогда можно всегда cf делать, я правильно понял?

(66) Тут, похоже, уже никто никого не понимает.
Ну да ладно.
по крайней ссылке всё крайне разумно расписано.
Кому надо разберется. Мне в эти дебри лесть сложно и безынтересно. Так что я спать =)

http://forum.infostart.ru/forum14/topic30935/

(71) Вот ответ который я искал я так понимаю такой
"как я понимаю, я могу обновить без проблем сколько угодно релизов при двух условиях:
1) обновление не удаляет объектов из предыдущй версии конфигурации
2) в обработке "обновление конфигурации" описан порядок обновления для всех моих релизов  "
Правильно?

(72) Идеологически да.

Ясно! Большое спасибо!

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

Сабж я имею ввиду, я считаю такой подход правильный, ситуацию из (22) считаю надуманной на практике не встечал, никто из уважаемых гуру я так понял тоже не встречал, или просто не признаются, я не думаю что в 1С сидят олени и будут что то пытаться тянуть из удаленных объектов. Да и синтаксис не позволит такое :).

(71) Чушь, там и сказали что чушь, ты код смотрел "ТекущаяВерсияИБ" это константа которая меняется прям в обработке последовательно от обновления к обновлению, т.е. все отрабатывает корректно, еще аргументы?

(76) Ну все понятно, пришли к выводу что почти все обновляют cfником. Я только не понял что вы имели ввиду под цфу + цф?

То что в (0) у тебя, я же сказал в (76). Кто обновляет цфником и сидит на одной конфе и дела передает потом тому кто за ним приходит пусть сидят, для коллективной работы такой подход неприемлим.

Ясно короче cfu это самый правильный вариант. Просто у кого не спрошу все cfниками прыгают.......

(78) сменить версию конфы после сф - задача на 15 минут.
И будут твои фильтры великолепно работать.
Но сидеть и пыжиться с обновлением по сфу последовательно на каждом релизе - это просто бред, ИМХО.
Я как-то пытался восемь релизов в БП обновить последовательно у заказчика...
Рабочий день в мусорку. Бухи ворчат (им работать низя).
Сервак 16 ядер по 2,7 оперативки на 8 Гигов.
Обновил только три.

Так что - ХЗ

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

(81) Ну так я тебе это же самое и говорил тут (64)
В форме сравнения у тебя будет две колонки с перечислением всех изменённых реквизитов.
Просто смотришь те, которые отсутствуют в сравниваемой конфигурации и всё.
Да и то, если пропустишь - объединение не удалит у тебя ничего ненужного. Просто будет болтаться лишний реквизит. Вот и всё.
А версию обновить можно - просто "прогнав" сфушки через свою конфигурацию с пустыми изменениями. Это будет куда быстрее, чем обновляться последовательно.

(80) Хм, ну это уже аргументированный подход, это интереснее. И как выкручиваешься если скажем треть объектов с   поддержки снята? Это не 15 минут далеко будет. Плюс при постановке на поддержку мусор весь остается в конфиге и тебе придется руками удалять то что удалилось бы автоматом. Т.е. потратить придется время на эти манипуляции. Но вцелом если нельзя но очень хочется то наверное можно и так. И кстати почему бухам нельзя работать, обновляй себе релиз за релизом в конце конфиг бд обновишь и вроде как все.

(82) "А версию обновить можно - просто "прогнав" сфушки через свою конфигурацию с пустыми изменениями." Вот это что имеется ввиду?

(84) Я так понимаю взять пустую базу и обновить на последний релиз, чтобы быстро получить последний cfник.

(83) Вся суть то как раз чтобы обновлять БД после каждого обновления, вроде как

(85) Я думаю что "А версию обновить можно - просто "прогнав" сфушки через свою конфигурацию с пустыми изменениями." относится к "сменить версию конфы после сф - задача на 15 минут".

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

(87) Если БД обновлять в самом конце, тогда это ни как не отличается от обновления cfников последнего релиза на сколько я понимаю, т.к. если объект удалили какой то во втором релизе например, то обработка его уже не найдет, а еслиб запускали по порядку то нашла бы до того как его удалили.

(82) Я только не понял вашу фразу "отсутствующие в табличке справа - переименуй их по семантике" не понял что это значит, вот нашли мы что 1С удалила реквизит УдалитьСотрудник, и что тогда? Может просто снять галочку чтобы она его не трогала, и потом как выполниться обработка ,удалить его в ручную?

(88) Откуда вот это вот про удаленные объекты объясни, покажи мне место в обработке обновления которое реально обращается к удаленному объекту, ну нафига с него что то читать если его удалили, я вот как программист не понимаю каким извращенным мышлением надо обладать чтобы обращаться тому чего нет. И еще раз, если такое и будет то синтаксис такое не пропустит, я думаю как то так, если кто то может привести пример или хотя бы аргументированное мнение обратного то я с удовольствием его выслушаю и приобрету бесценный опыт, но пока не вижу таких аргументов. При обновлении цфником ты теряешь конфиг поставщика, придется потом ставить снова на поддержку. Наверное если нельзя но очень хочется то можно по другому, но это частные случаи имхо.

(89) cfником можно обновить через поддержку ,а не через объединение и не потерять поставщика!
А про удаленный реквизиты я все это не сам придумал ,а прочитал вот тут http://infostart.ru/public/18596/
Может быть так раньше делали ,а сейчас не делают, если ты говоришь что реально такого ни когда не видел, тогда получается можно и вправду спокойно cfниками обновлять перепрыгивая!

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

(91)Ясно, короче говоря через 90 постов , вывод то как описано в (0) самый безопасный вариант?
Осталось только найти табличку по обновлению, какие настройки нужно тащить из релиза в релиз, а какие можно только в последний добавить. Может кто скинуть?

Вот только самый последний вопрос к вам еще остался =)
Не понял ваш пост (29), о каких отличиях идет речь, вроде бы в (26) как раз и говорилось о том к чему мы в итоге пришли.

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

в (29) я как раз подразумевал что не надо конфиг бд каждый раз обновлять, и изменения по объектам после каждой цфушки тоже не стоит вносить, все должно быть включено в последнюю цфку, после которой будет обновляться конфиг БД. Основная конфига будет собрана и конфиг бд корректно обновиться, и за ним и база при запуске предприятия.

т.е. цфу - цфу - цфу - цф с изменениями, и затем только конфиг бд обновлять

Обновляем 3 раза цфу потом вносим изменения и обновляем БД, что за цф последняя не понял.

Все таки скорей всего нужно запускать предприятие каждый раз как мне кажется. Ну ладно над этим еще можно подумать. В целом все ясно. Спасибо большое за подробные ответы!

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

(69) Единственный релиз по БП который нельзя было пропускать, это 1.5.22. И то это было связанно с переходом на 1.6

Все остальные релизы ни разу небыло проблем с перескакиванием

Но тебя же этот ответ не устраивает, ты же начинаешь рассуждать, а вдруг ...

(75) Необязательно

(76) В 2.0 висят хвосты от документов от 1.6, причем они там не юзались никогда, но до сих пор с первых релизов висят документы с префиксом "Удалить"

(82) В первых релиза БП 1.5 была такая засада, когда они не могли определится куда засунуть реквизит в регистр, толи в реквизит, толи в ресурс. Так что было весело.

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

(88) Ты же сам мифический пример приводил:
Был реквизит пользователь. Потом его переименовали в реквизит ПользовательУдалить и создали реквизит ФизЛица. Перенесли все данные из реквизита Пользователь в свой.
Затем удалили реквизит ПользовательУдалить.
В итоге в конечной таблице сравнения ты увидишь отсутствующий слева реквизит Пользователь и отсутствующий справа реквизит ФизЛица.
Отменяешь обновление, переименовываешь Свой реквизит Пользователь в ФизЛица и, вуа-ля - теперь они сопоставляются.
Должны, по-крайней мере =)
Лично я такого ещё ни разу не встречал =)

(104) Я об этом еще написал в прошлой ветки, еще в первом посте, но ты же фантазию включил. Если б да кабы, да во рту выросли б грибы ....