Добрый день!
Есть очень сильно доработанная 1С УПП.
Обновления производились по острой необходимости путем перекидывания кусков кода и объектов из *.cf файлов.
Стоит задача обновить до актуального релиза(пропущено 19 ключевых релизов).
Можно ли в копии подготовить cf файл последнего релиза с добавлением всех доработок, а потом обновить рабочую базу последовательно файлами cfu и в финальную версию закинуть все доработки?

>Можно ли в копии подготовить cf файл последнего релиза с добавлением всех доработок, а потом обновить рабочую базу последовательно файлами cfu и в финальную версию закинуть все доработки

извращения обязательны?

(1) Просто подготавливать 19 файлов с доработками очень много по времени

разрешаю подготовить 1

(0)кто то знает про флаг "показывать дважды измененные" ?

(3) +1

(4) с учетом

"по острой необходимости путем перекидывания кусков кода и объектов из *.cf файлов"

толку от него...

да, в таком варианте ИД послетали

предопределенные конечно тоже руками переносились и свои id имеют....

(4) Там практически от каждого релиза куски есть, поэтому даже с этим флагов выходит пол конфы

при желании все можно вот только зачем?

(9) и изменения конечно же не документировались?

(11) Конечно же нет

Есть обработка ОбновлениеИнформационнойБазы в процедуре ВыполнитьОбновление() есть указание на исходный релиз?

(12) тогда документируйте и потом обновляйте

(13) исходный релиз должен быть в конфе поставщика

возни будет много, но все возможно

(13)Исходный релиз есть

(17) сравнивайте, анализируйте и обновляйте
19 обновлений готовить не нужно

заодно и рефакторинг устроите

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

нужно анализировать процедуры обновления, чтобы не потерять нужное по дороге... 19 релизов - могли выкинуть что-то по дороге

Замути проект.

(21) так они же при обновлении отработают

(18) за 19 релизов что то могло появится новое , использоваться, а потом исчезнуть. так нельзя

http://catalog.mista.ru/public/18562/
http://catalog.mista.ru/public/18596/

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

(23) если остались в "библиотеке" процедур обновления

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

(26) включать мозг лучше всего в момент когда делаешь свои дописки.

(13) уточняю
см. ОбщийМодуль.БиблиотекаОбновленияИнформационнойБазыПереопределяемый Функция ОбработчикиОбновления()

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

(31) тогда сразу форматируй винты

(32)???

(31) а при накатывании с доработками что будет? они будут затираться?

(29) может это "наследство"

(34) Да

метаданные надеюсь - тоже...

(37) Нет, добавленные объекты при обновлении не затираются

(36) тогда есть риск потери данных

(38) добавленные нет, а измененные очень даже затираются

но почему никто не вспоминает, что в УПП 1.3 уже некоторое время рекомендовано выполнять обновление не с использованием CFU, а на CF ? Или эта багофича только комплексным досталась?

(0)
Стратегия примерно такая:
1. Готовишь последний релиз - переносишь все доработки.
2. Анализируешь добавленные/измененные реквизиты между релизами.
3. Анализируешь обработки обновления.
4. Пробуешь добавить новые реквизиты в текущий релиз, засекаешь время. Если по времени критично, то стараешься разбить на интервалы.
5. Пробуешь запустить обработки обновления, засекаешь время, разбиваешь на интервалы.
После п.4,п.5 имеешь представление, сколько времени потребуется для обновления конфиги.
6. Накатываешь реквизиты в рабочую БД
7. Запускаешь обработки обновления на рабочей БД.
8. Накатываешь последний релиз в рабочую БД.
Обновлял по такой схеме заводик, который работал в режиме почти 27/7. Иногда были окна в пару часов. И там релизов пропущено было поболе.

>6. Накатываешь реквизиты в рабочую БД
>7. Запускаешь обработки обновления на рабочей БД.
>8. Накатываешь последний релиз в рабочую БД.

достаточно взять cf от копии и загрузить

(43) Если база небольшая, то да. В моем случае, при большом количестве объектов, если загрузить из cf все новые реквизиты, реструктуризация некоторых таблиц занимала больше суток.

(31) в принципе этот вариант вполне может прокатить без потери данных, но осторожно.
В принципе есть вероятность того что, к примеру, реквизит был с типом Число 10.3, ты поставил 10.6, а в одном из релизов 1С изменили ему тип на 10.4, тогда твои числа в этом реквизите округлятся до 4х знаков (если не снимишь галочку с обновления реквизита)

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

(0) Обновляй последовательно, заодно в доработках разберешься :)

(46) какая разница? что цф, что цфу
если десять релизов назад убрали обработку обновления, то в новом цф она не появится

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

(48) там не разница, а тупая нехватка памяти для заврешения обновления, если оно делается через цфу.

только я на эту тупость наступил именно при обновлении КА 1.1 и лично у меня просто не было под руками УПП 1.3, но где-то мелькали перед глазами общие пояснения, что там такая же история

(50) у вас наверное сервер 32x

(52) Кстати, да - есть рекомендация использования 64х версию клиента. Сервер и так 64х уже много лет