Имя: Пароль:
1C
1С v8
ЗУП 3.1.14 почему при обновлении старая конфигурация поставщика изменена
0 Антиквар
 
29.12.20
18:13
Всем привет!
Переходим с 3.1.10 на 3.1.14.
Конфигурация стандартная, за исключением расширений и пары допилов в конфигурации.
Поскольку сильно отстали в обновлениях, приходится обновлять подряд много релизов.
И почему-то в каждом таком обновлении с релиза на релиз, в самом конце, в таблице сравнения объектов, очень много расхождений, где написано, что в старой конфигурации объект изменен по-сравнению со старой конфигурацией поставщика.
Я понимаю, если бы в новой конфигурации изменялись объекты, которые мы меняли, но меняются стандартные нетронутые объекты, и при этом показывает, что в нашей базе такие объекты изменены по-сравнению со старой конфигурацией поставщика. Раньше такое тоже бывало, но если разворачивать плюсики, чтобы увидеть конкретно в чем различие, то это всегда была справочная информация. А теперь не всегда справочная, теперь формы различаются. И главное что таких объектов достаточно много.
Как это объяснить?
1 Фрэнки
 
29.12.20
19:00
Могу предположить, что это всё из-за того, что пару допилов вам пришлось в конфигурацию вписать. Т.е. конфиг с замка снят.
А значит, и вообще при любом, но при обновлении обновлениями точно, отстраивается, пересобирается конфа поставщика.

Чтоб подобного рода проблемы мне самому глаза не мозолили, а в еще большей степени - для экономии времени и оперативной памяти при обновлении,
стараюсь вытаскивать полный дистриб, в котором лежит простой CF , а не CFU
При обновлении на поддержке из CF просто загружается конфиг поставщика - не сравнивается, не объединяется, не нужно это совершенно. Готовый CF поставщика вливается на свое место.

И уже затем идет процесс получения конфигурации текущей и далее она применяется к конфигурации базы.

Но если "замок" снят, то вне того были какие-то модификации у самого разработчика или не было, просто применяется механизм сравнения и объединения объектов.

И это еще один аргумент для меня, когда я могу где-то сказать, что на "боевой базе" использование режим "разрешены изменения с сохранением поддержки" бессмысленный.
В режиме обязательного предварительного тестирования все равно будет получен CF, который просто можно установить/залить из файла на "боевую базу", поскольку все мыслимые и немыслемые телодвижения уже произошли во время подготовки обновления.
Но это не означает, что надо игнорировать полностью пошаговые применения типовых к базе, когда типовая при скачках от релиза к релизу сильно меняет структуру и данные служебными процедурами обновления перелопачиваются кардинально.
2 Фрэнки
 
29.12.20
19:02
Т.е. прыжок через много много релизов все равно желательно совершать множеством прыжков.
3 Антиквар
 
29.12.20
19:18
Конфигурация на поддержке с возможностью изменений.
(2) в том и дело, одним CF не обойдешься, всё-равно нужно соблюсти порядок накатывания обновлений (ну или полных CF-файлов) для того, чтобы в режиме предприятия все регламентные операции сделались.
Я понимаю, что если конфа на полной поддержке, то никакого сравнения объектов не надо. Но у нас есть пара своих объектов.
4 Фрэнки
 
29.12.20
19:45
(3) конечно, прыжки только одними CF - если используешь CFU, то происходит сборка. И каждый раз эта сборка происходит заново.
5 Антиквар
 
29.12.20
20:03
(4) "И каждый раз эта сборка происходит заново"
Заново происходит сравнение конфигураций, но почему заново собирается конфигурация поставщика? Она же уже есть в базе и она не должна меняться. Она должна лишь сравниться с текущей конфигурацией, а последняя в свою очередь с новой конфигурацией поставщика.
Ну даже если так, то почему в релизе 3.1.14 я стал наблюдать такую картину. Во всех предыдущих такого масштаба не было.