Какая разница каким файлом обновлять конфигурацию *cfu или *cf
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Что-то я тут полного правильного ответа так и не увидел.
CF - полная конфигурация, в CFU - только описания изменений по сравнению с определенными предыдущими релизами. При обновлении на CFU конфигуратор сначала строит полный CF и на него обновляет, поэтому может быть немного дольше. Результат будет одинаковым. Удобнее, конечно, обновляться с CF.
Если вам нужно обновиться на 10 релизов подряд, попробуйте сначала обновиться через CF, т. к. это быстрее. После этого в режиме предприятия если не возникнет ошибки при обновлении, то всё ОК. Если возникнет ошибка, что не найден какой-то реквизит (вероятность ~1%), то тогда нужно обновиться сначала на какой-то промежуточный.
Я всегда держу пустые базы с типовыми конфигурациями, которые обновляю чтобы получить полный CF вместо CFU.
В таблице релизов на сайте 1С не РЕКОМЕНДУЕМЫЙ порядок обновления, а просто для каждого CFU написано, с каких релизов этот CFU может обновить, для обновления с других релизов в этом CFU просто нет данных для обновления и ВСЁ!
При обновлении сразу на нужный CF вы в перспективе сэкономите кучу времени, а в 1% случаев (кажется, за 10 лет 1 раз такое было) просто откатитесь и сначала обновитесь на какой-то промежуточный. При чём полный перенос доработок у вас уже будет сделан (вам же не требуются доработки форм в промежуточном релизе, на котором пользователи работать не будут).
CF - полная конфигурация, в CFU - только описания изменений по сравнению с определенными предыдущими релизами. При обновлении на CFU конфигуратор сначала строит полный CF и на него обновляет, поэтому может быть немного дольше. Результат будет одинаковым. Удобнее, конечно, обновляться с CF.
Если вам нужно обновиться на 10 релизов подряд, попробуйте сначала обновиться через CF, т. к. это быстрее. После этого в режиме предприятия если не возникнет ошибки при обновлении, то всё ОК. Если возникнет ошибка, что не найден какой-то реквизит (вероятность ~1%), то тогда нужно обновиться сначала на какой-то промежуточный.
Я всегда держу пустые базы с типовыми конфигурациями, которые обновляю чтобы получить полный CF вместо CFU.
В таблице релизов на сайте 1С не РЕКОМЕНДУЕМЫЙ порядок обновления, а просто для каждого CFU написано, с каких релизов этот CFU может обновить, для обновления с других релизов в этом CFU просто нет данных для обновления и ВСЁ!
При обновлении сразу на нужный CF вы в перспективе сэкономите кучу времени, а в 1% случаев (кажется, за 10 лет 1 раз такое было) просто откатитесь и сначала обновитесь на какой-то промежуточный. При чём полный перенос доработок у вас уже будет сделан (вам же не требуются доработки форм в промежуточном релизе, на котором пользователи работать не будут).
Скорость обновления одинаковая. Но если ты будешь "перескакивать" на такие релизы, которые не допускает *.cfu перескочить, то получишь проблем.
Из-за реструктуризации могут потеряться данные.
Короче, надёжнее обновлять рабочие базы только*.cfu'шками.
Ещё после каждой итерации обновления не забывай запускать базу в режиме предприятия и прогонять обработки обновления конфигурации.
Из-за реструктуризации могут потеряться данные.
Короче, надёжнее обновлять рабочие базы только*.cfu'шками.
Ещё после каждой итерации обновления не забывай запускать базу в режиме предприятия и прогонять обработки обновления конфигурации.
На самом деле, разница в том, что обновление - это не только "прикрутить" новую конфигурацию. Часто нужно обрабатывать и данные. .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 релизов), но зато гарантирует отсутствие ошибок в дальнейшем.
(31)Я не про то что бывает, я про то, что за 12 лет у меня не было такого. А обновлял я много, очень много, и даже приходилось исправлять базы обновленные с пропуском релизов, это те которые обновляли до меня. Это еще те танцы с бубном.
Так что обновлять надо последовательно, с обязательным запуском на реструктуризацию.
Так что обновлять надо последовательно, с обязательным запуском на реструктуризацию.
(8) я конечно не знаю где кто вам что доказывал.
Я понимаю, что вы пытались описать проблему, которая может возникнуть при обновлении, но вынужден согласится, что во фразе:
Часто нужно обрабатывать и данные. .cfu это учитывают, а .cf - это "голая" конфигурация, без информации о том, как обновить данные.
действительно написана какая-то фигня.
Я понимаю, что вы пытались описать проблему, которая может возникнуть при обновлении, но вынужден согласится, что во фразе:
Часто нужно обрабатывать и данные. .cfu это учитывают, а .cf - это "голая" конфигурация, без информации о том, как обновить данные.
действительно написана какая-то фигня.
(10) да нет. Суть передает высказывание
а вот это
абсолютно непонятная (более того - сбивающая с толку) формулировка. Как .cfu что-то там учитывают в обработке данных сможете рассказать? И почему это сакральное знание о том, как обновить данные, недоступно вдруг файлу .cf? :) В подобной формулировке у новичка может сложится впечатление, что cfu это какой-то особенный формат файла, который сам выполняет какие-то дополнительные действия в процессе обновления, в отличие от .cf. Что естественно неверно.
Хочется надеяться что это просто неудачная формулировка, а не искреннее заблуждение.
ЦФ - это полноценная конфигурация, а ЦФУ содержит в себе только разницу между конкретными версиями конфигураций.
а вот это
Часто нужно обрабатывать и данные. .cfu это учитывают, а .cf - это "голая" конфигурация, без информации о том, как обновить данные.
абсолютно непонятная (более того - сбивающая с толку) формулировка. Как .cfu что-то там учитывают в обработке данных сможете рассказать? И почему это сакральное знание о том, как обновить данные, недоступно вдруг файлу .cf? :) В подобной формулировке у новичка может сложится впечатление, что cfu это какой-то особенный формат файла, который сам выполняет какие-то дополнительные действия в процессе обновления, в отличие от .cf. Что естественно неверно.
Хочется надеяться что это просто неудачная формулировка, а не искреннее заблуждение.
Я делаю так у меня рабочая конфигурация модифицирована. Когда выходит новый релиз я создаю новую базу на новом релизе модифицирую её так как мне нужно. После чего создаю *cf рабочей базы и в конфигураторе релизной с модификациями базе создаю файл обновления на основе *cf рабочей базы. И при помощи полученного *cfu файла обновления обновляю рабочую базу.
Чем чреват мой способ обновления?
Чем чреват мой способ обновления?
В принципе, безопасной можно считать цепочку обновлений, помеченных в колонке "Диск 1С:ИТС" на
Важно заранее сделать бекап папки/базы SQL и поставить платформу, необходимую последнему релизу в цепочке.
(16)
В принципе, ничем, разве что я бы лучше использовал cf вместо cfu.
Важно заранее сделать бекап папки/базы SQL и поставить платформу, необходимую последнему релизу в цепочке.
(16)
В принципе, ничем, разве что я бы лучше использовал cf вместо cfu.
(19) Не надо ничего записывать. Разница между основной конфигурацией и конфигурацией поставщика расскажет обо всём сама.
Главное конфигурацию поставщика держать типовой и того же релиза, что и основная.
Если бы я был за тобой следующим, то твои писульки бы отложил и запустил сравнение "поставщика" с основной. Там всё более, чем наглядно.
Главное конфигурацию поставщика держать типовой и того же релиза, что и основная.
Если бы я был за тобой следующим, то твои писульки бы отложил и запустил сравнение "поставщика" с основной. Там всё более, чем наглядно.
(21) в (16) как я понял предлагают сделать файл поставки из обновленной копии базы , а потом обновить этим файлом основную базу - вы понимаете к чему это приведет ? Полностью согласен с (18) будет полный ахтунг, и подписывай ты свои изменения , не подписывай все может накрыться медный тазом. Конфигурация поставщика всегда должна оставаться типовой неизмененной.
(22)
а как тогда сделать дополнение к типовой конфе если необходимо ввести новые документы журнал к ним, а иногда требуется в стандартные документы добавить реквизиты.Ну или изменить код в общих модулях или обработках. Я знаю есть расширение но оно не для всего подходит
Конфигурация поставщика всегда должна оставаться типовой неизмененной
а как тогда сделать дополнение к типовой конфе если необходимо ввести новые документы журнал к ним, а иногда требуется в стандартные документы добавить реквизиты.Ну или изменить код в общих модулях или обработках. Я знаю есть расширение но оно не для всего подходит
(23) Вам надо немного получить вопрос обновления не типовых , получается мы с вами немного говорим о разном , если в (16) вы имели ввиду то что на копии делаете обновление а потом через меню "Выгрузить конфигурацию в файл" делаете файл cf и им обновляете основную базу , это одно в этом случае все будет нормально , но если Вы после обновления делаете файл Cfu через меню Создание файлов поставки ( не помню как дословно звучит) , в этом случае ваши не типовые объекты , после обновления основной базы этим файлом станут типовыми ( появится желтый куб с замочком) и при следующем обновлении программа может удалить ваши данные , так как в типовом релизе не будет добавленных вами объектов
(16)
Допустим ты добавил новый объект. В конфигурация-поддержка-Настройка поддержки ты его увидишь. Для следующего программиста будет казаться, что это типовой объект. Плюс: что у тебя в полях "Конфигурация поставщика", "Поставщик" и "Версия"?
(19)
Представь себе бухгалтер вместо использования базы 1С ведёт всю бухгалтерию в тетрадке. Отчеты делает и сдает в Excel. Всё подробно фиксирует в тетрадке. Т.е. идёт подробное описание в тетрадке всех операций (даже в базе так подробно не описывают), но в базе пустота Как думаешь тот бухгалтер который придёт вместо него он оценит труды?
По вопросу:
Если всё делать грамотно и не перескакивать через несколько релизов (не предусмотренные разработчиком) то результат должен быть одинаковым. Но для этого нужно понимать что делаешь, если понимания нет - лучше действовать через "Конфигурация" - "Поддержка" - "Обновить конфигурацию" - "Поиск доступных обновлений (рекомендуется)".
Я делаю так у меня рабочая конфигурация модифицирована. Когда выходит новый релиз я создаю новую базу на новом релизе модифицирую её так как мне нужно. После чего создаю *cf рабочей базы и в конфигураторе релизной с модификациями базе создаю файл обновления на основе *cf рабочей базы. И при помощи полученного *cfu файла обновления обновляю рабочую базу.
Чем чреват мой способ обновления?
Чем чреват мой способ обновления?
Допустим ты добавил новый объект. В конфигурация-поддержка-Настройка поддержки ты его увидишь. Для следующего программиста будет казаться, что это типовой объект. Плюс: что у тебя в полях "Конфигурация поставщика", "Поставщик" и "Версия"?
(19)
я все изменения записываю что как делал и где изменял, надеюсь не будет плохими словами меня вспоминать)
Представь себе бухгалтер вместо использования базы 1С ведёт всю бухгалтерию в тетрадке. Отчеты делает и сдает в Excel. Всё подробно фиксирует в тетрадке. Т.е. идёт подробное описание в тетрадке всех операций (даже в базе так подробно не описывают), но в базе пустота Как думаешь тот бухгалтер который придёт вместо него он оценит труды?
По вопросу:
Какая разница каким файлом обновлять конфигурацию *cfu или *cf
Если всё делать грамотно и не перескакивать через несколько релизов (не предусмотренные разработчиком) то результат должен быть одинаковым. Но для этого нужно понимать что делаешь, если понимания нет - лучше действовать через "Конфигурация" - "Поддержка" - "Обновить конфигурацию" - "Поиск доступных обновлений (рекомендуется)".
(16)
1) при такой схеме (обновление рабочей через собственную поставку) ты заменяешь конфигурацию поставщика на свою (уже обновленную). Ничего смертельного в этом нет, но гораздо удобнее, когда конфигурация поставщика остается типовая. Тогда в любой момент можно не отходя от кассы проанализировать отличия от типовой. Для этого можно обновляться по такой схеме:
- в копии рабочей обновить конфигурацию поставщика и ее уже аккуратно сравнить/объединить с основной конфигурацией
- после того, как копия успешно прошла все испытания, делаешь просто выгрузку/загрузку конфы из копии в рабочую
2) ну и при любых раскладах нужно быть внимательным с мажорными обновлениями, когда издеваются над уже существующими метаданными - такие обновления могут подразумевать только последовательное обновление (ну, самый тупой пример - в одном релизе перенесли какие-то данные в другое место, а в другом релизе прибили старые метаданные. При кумулятивном обновлении будет потеря данных еще на этапе реструктуризации).
1) при такой схеме (обновление рабочей через собственную поставку) ты заменяешь конфигурацию поставщика на свою (уже обновленную). Ничего смертельного в этом нет, но гораздо удобнее, когда конфигурация поставщика остается типовая. Тогда в любой момент можно не отходя от кассы проанализировать отличия от типовой. Для этого можно обновляться по такой схеме:
- в копии рабочей обновить конфигурацию поставщика и ее уже аккуратно сравнить/объединить с основной конфигурацией
- после того, как копия успешно прошла все испытания, делаешь просто выгрузку/загрузку конфы из копии в рабочую
2) ну и при любых раскладах нужно быть внимательным с мажорными обновлениями, когда издеваются над уже существующими метаданными - такие обновления могут подразумевать только последовательное обновление (ну, самый тупой пример - в одном релизе перенесли какие-то данные в другое место, а в другом релизе прибили старые метаданные. При кумулятивном обновлении будет потеря данных еще на этапе реструктуризации).
Вы путаете , есть основная конфигурация где вы вносите все изменения добавляете все что душе угодно, есть конфигурация поставщика , которая как раз и служит при обновлении неким шаблоном по которому программа выявляет изменения внесённые в основную конфигурацию ( вообще там проходит несколько сравнений что бы выявить изменения основной конфигурации и изменений которые были добавлены Новым релизом , результатом этих сравнений является окно сравнения объединения где показаны все различия) так же существует конфигурация базы данных , это когда вы обновили основную конфигурацию и заходите в режим предприятия и заканчиваете обновления там
с 8.3. какого то при обновлении конфигуратор предлагает сохранить xml очень удобно. я один раз сильно изменённую сохраняю внимательно а потом схожие используя эти xml. в xml объекты те что были выбраны для обьединения и правила.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот