Имеется конфигурация УПП 1.3 (1.3.106.1), значительно измененная.
Необходимо обновить на последний релиз.
Процесс обновления, будет проходить через релизы:
1.3.111.1
1.3.110.3
1.3.109.1
1.3.108.2
1.3.107.1

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

Подскажите пожалуйста. Как это правильнее проделать.
Была подсказка, взять типовой релиз, имеющейся версии
конфигурации, наверное .cf файл. И обновить его последовательно,
на все необходимые релизы. А потом делать через сравнение
объединение. С настоящей базой.

Подскажите пожалуйста, как взять типовой релиз
текущей конфигурации?

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

ИЛИ

Конфигурация->Сохранить конфигурацию в файл

?

Если поддержка не отключена полностью, тогда оттуда.
Если отключена - то из дистрибутива

(2) Вроде полностью не снята.
Но, в о программе значится релиз 1.3.160.1.
А в поддержке, 1.3.85.3. ((((.

Пробую взять .cf вот от сюда, -

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

Верно? я его разверну и посмотрю что за релиз в о программе.

(3) сделай обновление на CF 1.3.106.1, сняв все флажки в сравнении-объединении

как результат у тебя конфигурация поставщика будет 1.3.106.1, а основная конфигурация затронута не будет

(4) То есть я качаю .cf 1.3.106.1
делаю сравнение объединение, сняв все флажки
и в поддержке становится 1.3.160.1 ?

(5) нет, делаешь
конфигурация - поддержка - обновить
и потом снимаешь все флажки

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

Да, или как в (6), через обновление со снятыми флажками. Только все равно проверь потом признаки поддержки по объектам.

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

(6) а что даст этот прием?

(7) Так конфигурация измененная!!!! как её можно ставить на поддержку?

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

(9) Есть режим "Объект поставщика редактируется с сохранением поддержки". Желтая коробка. Если серая коробка - ахтунг, при обновлении такой объект не обновится

(0) Документации по изменениям или автора идей по изменениям нет?

(9) Тебе перед обновлением надо чтобы в базе релиз основной конфигурации и релиз конфигурации поставщика стали одинаковыми.

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

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

(10) я буду последовательно, на каждый указанный релиз.
.cf 1.3.160.1 на все указанные в (0) с запуском режима
1с предприятия, после каждого обновления.

(12) Есть, знающий человек. Но я сам хочу попробовать.
Пока буду подготавливать релиз финальный. Проделав
последовательно все обновления.

(13) Нужно сделать да. Это описано в (6)?!

(14) Изучать я думаю долго. я хочу попрактиковаться.
Пока выгружаю .cf тестовой.
Буду все проделывать на тестовой sql server базе.
Так как, других вариантов нет.

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

Судя по несовпадению номеров релизов в конфиге от поставщика с основной - на основную просто накатывали заготовленный CF со всеми доработками в режиме "сравнить, объединить с конфигурацией из файла". Если в таком режиме, то наличие в базе "изменять с сохранением поддержки" не имеет никакого практического значения, кроме создания дополнительных проблем с архивацией базы и избыточным раздуванием размера каждого экземпляра архива примерно на 600-700 мб.

(17) А в каком режиме делать заготовочный .cf.
Других вариантов нет. 1с не увидит больше лицензию.
Только в тестовой копии в одной.

Да именно так видимо и делали, накатывали подготовленный .CF, как планируется сделать и сейчас!

Сейчас мне важно сделать (6) !!!! Пробую!

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

Я вижу последовательность обновления обычно так:
1) добыть такой CF, который отображается как релиз в основной базе (часто не совпадает с релизом конфы поставщика, если она вообще еще есть)
2) сравнение оригинального CF с текущим и подробная запись "а чего же там наобновляли до нас". Какое-то документирование, хотя бы кратко.
3) получение по цепочке целевого CF из оригинального
4) перенос в него всех доработок.
5) сравнение-объединение с основной и выполнение всех процедур, которые попросит типовая. К сожалению, есть риск хватануть такую процедуру перехода со сбоем и тогда придется накатывать на основную CF с промежутками, тогда хотя бы структурные изменения основной конфиги придется добавить в промежуточные обязательно и тратить время на промежуточные обновления.

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

(20) Можно и месяцы убить на подобное обновление ))
(16) Кто будет тестировать твои изменения?
Неплохо всё-таки добыть локальную лицензию и не мучить общий сервер.

Сейчас сделал обновить с .cf файла 1.3.160.1.
Там появилось окно объектов.
Где то стоят галки, где то нет, где то тусклые галки.
Мне все убирать галки?

(21) составляется довольно подробный план мероприятий и движутся по нему. Видел на практике, что поэтапное выведение конфиги УПП в актуальный релиз действительно было расписано на несколько месяцев. Изначально при внедрении УПП питали иллюзию, что смогут ее вообще не обновлять, а пользоваться конфигурацией БП. Затем все-таки приняли решение обновлять. Я бы уже и не обновлял. Но решение принималось без учета моего мнения :)

(22) смотря в чем обновляешь. У тебя есть база с типовой CF на поддержке? Тогда ничего не трогай, а просто обновляй

Убрал все галки, нажал ок.
Сейчас конфигурация поставщика 1.3.160.1.
Я правильно сделал?

(24) Да, нужно было, просто обновить со всеми галками.
Что бы он стал типовым. И потом последовательно на все
остальные релизы, что бы получить финальный .cf последнего релиза. Так же?

(26) Ну да. Тебе его все равно править в самом конце надо будет ручками и он должен быть перед этим быть типовым.

(26) но я бы взял чистую базу и в ней восставновленная типовая из конфиги поставщика и уже ее бы прогонял в финальный релиз

(10) нельзя так. ни на практике , ни в теории

(21) Добыл один фиолетовый ключ, YFSP на нем написано.
Как определить от 1с он или нет?

(30+) HASP, на нем надпись.

Обновляю на 1.3.107.1.

(22) Ты сейчас просто типовой 1.3.112.5 хочешь получить путем последовательного обновления типовой 1.3.106.1? Или уже за рабочую взялся? Я не понял что ты вообще делаешь.

(29) Можно.

(33) Да типовой, но пока 1.3.111.1 .
До 112 пока не дошли ещё.

(35) А в (22) ты делал, чтобы в твоей измененной 1.3.106.1* конфигурация поставщика стала тоже 1.3.106.1?

(34) не повторяйся. дай аргументы

(37) Ну ты же не дал аргументов.
Если в промежутке между релизами не было удаления объектов, с которых что-то куда то нужно перенести, и если в конфигурации кумулятивно зашиты процедуры программной конвертации данных, которые последовательно отработают (с 106 на 107, с 107  на 108 и т.д.), то обновление пройдет корректно.

+(38) и если с переименованиями объектов поставщик не балуется.

Возник такой вопрос.
Я привел конфигурацию поставщика к версии основной
конфигурации и конфигурации базы данных.
Обновив на .cf и убрав все галки с объектов при обновлении.
Конфигурация поставщика стала 1.3.160.1.
Сейчас, последовательно, с запуском режима 1с предприятие
обновляю на релизы:

1.3.111.1
1.3.110.3
1.3.109.1
1.3.108.2
1.3.107.1

нажимая, продолжить, что бы получить финальный релиз.

Нормальный ли такой подход при обновлении.
Что следует делать далее? Получив, финальный релиз?

(40) Тебе надо записать, какие объекты были "дважды изменены", то есть были изменены пользователем и поставщиком в новых релизах. Надо использовать фильтр в дереве. По идее в дереве можно сразу настроить правила объединения, чтобы потом ручками меньше все переносить. После наката всех обновлений надо по дважды измененным объектам вручную восстановить изменения пользователя, которые были в 1.3.106.1*.

+(41) А в конце верификацию сделать хорошо бы. Например см. https://spk-code.blogspot.com/2015/12/1.html?showComment=1537508158355#c6651732004750810555

(41) А от куда их нужно выписать?
Где их можно увидеть?

(38) я насчитал 2 раза "если", а в первом сообщении ты был более категоричен. Может еще подумаешь стоит ли перепрыгивать через релизы?

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

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

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


{ОбщийМодуль.ПолныеПрава.Модуль(707)}: Ошибка при получении значения атрибута контекста (ТекущийПользователь)
        Запрос.УстановитьПараметр("ТекущийПользователь", ПараметрыСеанса.ТекущийПользователь);
по причине:
{МодульСеанса(24)}: Слишком много фактических параметров
        Запрос.УстановитьПараметр("ТекущийПользователь", ПараметрыСеанса.ТекущийПользователь);

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

так как ошибка не явная совсем

(30) По идее, да.
ну поставь драйвер, воткни, проверь....

(46) Посмотри что конфигуратор показывает, какой релиз поставщика и основной конфигурации. Почисти кэш.

(44) Кто бы говорил про категоричность (см. (29)).
УПП уже, по-моему, лет 5 1С не курочила так, чтобы это обновлению через несколько релизов помешало.

(49) Да запустил я его. Для локального пользования.

Сейчас вопрос вот с обновлением. Что делать с ним?
Что желать с (46) и (47). Вообще конечно, загружать
копию рабочей в тестовую и пробовать все по новой.
Надеясь что не будет нового сбоя!

(50) я вижу упп. и вижу там объекты с названием "Удалить...".
поэтому категорично (29)

(52) Да они там годами висят, никто их не удаляет, а значит программная конвертация все из них куда надо уже давно перенесла.
А если при подготовке обновления конвертация ругнется - ну тогда да, последовательно нужно сделать. Или схитрить и сделать чтобы объект не удалился.

(43) В дереве можно включить фильтр по дважды измененным объектам.
Я их в эксельке помечаю, чтобы не забыть.

(54) То есть фильтр, дважды измененные объекты
это и есть отличия от типовой конфигурации?
Что и было изменено?
Беру конфигурацию, сравниваю её с типовым релизом её же.
И вижу эти объекты?

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

В остальных объектах, измененным пользователем, а также в нетиповых объектах, тоже возможно потребуется что-то менять при обновлении, если, например, использовалась процедура общего модуля, а модуль переименовали. Правда в УПП почти не меняется ничего.

Я бы повторил свой совет из (14).

(56) Я действую в процессе.
Конечно изучаю. Статей полно читаю, выбираю какие лучше.

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

Так же?

Это и будет то что доработано, изменено по сравнению с типовой конфигурацией!

(57) Да