По теме из базы знаний
- Технология обновления нетиповых конфигураций 1С:Предприятия 7.7
- Технология обновления нетиповых конфигураций 1С:Предприятия 8 (редакция 12.04.2012)
- Пакетное обновление типовых конфигураций 1С 8.2
- Обновление измененной типовой конфигурации 1С на платформе 8.3 за 7 дней. Как сократить время. Программа и методика испытаний
- Автообновление типовых конфигураций 1с8
Найденные решения
(2) Бред. Из файла CF тоже вполне можно обновляться (если он содержит конфигурацию поставщика и описание обновлений).
А даже если и не содержит конфигурации поставщика - то тоже можно обновиться без потери данных методом сравнения и объединения (если номер нового билда поддерживает переход с текущего билда).
А то что ты написал - это при обновлении методом "Сравнить и объединить" в случае, когда билд нового релиза не подходит для обновления текущего.
А даже если и не содержит конфигурации поставщика - то тоже можно обновиться без потери данных методом сравнения и объединения (если номер нового билда поддерживает переход с текущего билда).
А то что ты написал - это при обновлении методом "Сравнить и объединить" в случае, когда билд нового релиза не подходит для обновления текущего.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) На самом деле, разница в том, что обновление - это не только "прикрутить" новую конфигурацию. Часто нужно обрабатывать и данные. .cfu это учитывают, а .cf - это "голая" конфигурация, без информации о том, как обновить данные.
Чувствую, нужен пример?
Был у нас документ Док. У него реквизит Рекв определённого типа.
В какой-то момент разработчик решил, что тип Рекв должен быть другим. Что он делает?
1) переименовывает Рекв в удалить_Рекв.
2) создаёт новый реквизит Рекв с нужным типом
3) (!!!) пишет обработку, которая при обновлении "перекачает" данные из удалить_Рекв в Рекв.
Всё! Система опознаёт объекты не по имени, а по идентификатору, так что, накатив .cfu ты получишь именно такую последовательность:
1) переименовался старый реквизит
2) создался новый реквизит
3) данные переачались в новый реквизит
Через какое-то время старый удалить_Рекв убирают из конфигурации, и у тебя при очередном обновлении происходит
4) удалить_Рекв удаляется навсегда.
А теперь предположим, что ты накатил сразу второй .cf, что будет?
1) УДАЛЯЕТСЯ старый Рекв.
2) Создаётся новый Рекв.
3).... а нет третьего! Данные не обрабатываются!
То есть, ты теряешь все данные в Рекв.
Резюме: лучше обновляться с .cfu. И после КАЖДОГО обновления запускать программу и давать ей обработать данные. Знаю, это муторно (особенно при обновлении этак через 10 релизов), но зато гарантирует отсутствие ошибок в дальнейшем.
Взято отсюда
Чувствую, нужен пример?
Был у нас документ Док. У него реквизит Рекв определённого типа.
В какой-то момент разработчик решил, что тип Рекв должен быть другим. Что он делает?
1) переименовывает Рекв в удалить_Рекв.
2) создаёт новый реквизит Рекв с нужным типом
3) (!!!) пишет обработку, которая при обновлении "перекачает" данные из удалить_Рекв в Рекв.
Всё! Система опознаёт объекты не по имени, а по идентификатору, так что, накатив .cfu ты получишь именно такую последовательность:
1) переименовался старый реквизит
2) создался новый реквизит
3) данные переачались в новый реквизит
Через какое-то время старый удалить_Рекв убирают из конфигурации, и у тебя при очередном обновлении происходит
4) удалить_Рекв удаляется навсегда.
А теперь предположим, что ты накатил сразу второй .cf, что будет?
1) УДАЛЯЕТСЯ старый Рекв.
2) Создаётся новый Рекв.
3).... а нет третьего! Данные не обрабатываются!
То есть, ты теряешь все данные в Рекв.
Резюме: лучше обновляться с .cfu. И после КАЖДОГО обновления запускать программу и давать ей обработать данные. Знаю, это муторно (особенно при обновлении этак через 10 релизов), но зато гарантирует отсутствие ошибок в дальнейшем.
Взято отсюда
(2) Бред. Из файла CF тоже вполне можно обновляться (если он содержит конфигурацию поставщика и описание обновлений).
А даже если и не содержит конфигурации поставщика - то тоже можно обновиться без потери данных методом сравнения и объединения (если номер нового билда поддерживает переход с текущего билда).
А то что ты написал - это при обновлении методом "Сравнить и объединить" в случае, когда билд нового релиза не подходит для обновления текущего.
А даже если и не содержит конфигурации поставщика - то тоже можно обновиться без потери данных методом сравнения и объединения (если номер нового билда поддерживает переход с текущего билда).
А то что ты написал - это при обновлении методом "Сравнить и объединить" в случае, когда билд нового релиза не подходит для обновления текущего.
3. Зачем же сразу "Бред". Человек старался, объяснял, на что тратят франчайзеры время и деньги пользователей при обновлении. ;)
p.s. Года два-три назад, пришлось обновлять большое количество баз, которые не обновлялись больше двух лет. Обновил все CF файлами, но за два подхода, т.к. был промежуточный, без которого было невозможно обновить. (Обновление прошло успешно.)
p.s. Года два-три назад, пришлось обновлять большое количество баз, которые не обновлялись больше двух лет. Обновил все CF файлами, но за два подхода, т.к. был промежуточный, без которого было невозможно обновить. (Обновление прошло успешно.)
(9) CFU имеет точно такую же последовательность как и CF, и точно ту же совместимость по версиям. Поэтому нет никакой разницы - обновлять через официальные CF или CFU - последовательность и возможности абсолютно одинаковые.
быстро обновить конфу по ключевым CF
Опять вы за свое... Нельзя "быстро" обновить старую версию с помощью одного только CF. Нужна точно такая же последовательность (цепочка совместимости) из нескольких версий с обязательной постобработкой данных!
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот