
Рассмотрим на примере обновления конфигурации "1С:Бухгалтерия предприятия 8" с версии 1.5.9.6 на версию 1.6.11.7.
Разработчики фирмы 1С рекомендуют обновляться в порядке предусмотренном *.cfu файлами.
Данные по обновлениям можно найти на страничках:
Бухгалтерия предприятия - http://users.v8.1c.ru/Accounting.aspx
Зарплата и Управление Персоналом - http://users.v8.1c.ru/HRM.aspx
Управление торговлей - http://users.v8.1c.ru/Trade.aspx
Управление производственным предприятием - http://users.v8.1c.ru/Enterprise.aspx
Эти разделы доступны для владельцев конфигураций, у которых есть действующая подписка на диск ИТС. Также данные по обновлениям можно найти в новостях фирмы 1С - http://v8.1c.ru/news/newsArchive.jsp
Ключевой фразой для поиска будет "Вышла новая версия". На основании этих данным можно построить список обновлений.
Например, в нашем случае это будет так:
1.5.10.3 - 1.5.8.5 и 1.5.9.6
1.5.11.5 - 1.5.10.3
1.5.12.1 - 1.5.10.3 и 1.5.11.5
1.5.13.6 - 1.5.12.1
1.5.14.4 - 1.5.13.6
1.5.15.3 - 1.5.14.4
1.5.16.3 - 1.5.15.3
1.5.17.3 - 1.5.16.3
1.5.18.4 - 1.5.17.3
1.5.19.6 - 1.5.18.4
1.5.20.2 - 1.5.17.3, 1.5.18.4, 1.5.19.6
1.5.21.2 - 1.5.20.2
1.5.22.3 - 1.5.20.2, 1.5.21.2
1.6.2.39 - 1.5.17.3, 1.5.18.4 и 1.5.19.6
1.6.3.2 - 1.5.17.3, 1.5.18.4, 1.5.19.6, 1.5.20.2 и 1.6.2.39
1.6.4.7 - 1.5.20.2, 1.5.21.2, 1.6.3.2
1.6.5.2 - 1.5.21.2, 1.5.22.2, 1.6.3.2, 1.6.4.7
1.6.5.3 - 1.5.21.2, 1.5.22.2, 1.5.22.3, 1.6.3.2, 1.6.4.7
1.6.6.8 - 1.5.22.2, 1.5.22.3, 1.6.5.2, 1.6.5.3, 1.6.5.4
1.6.7.3 - 1.5.22.2, 1.5.22.3, 1.6.5.2, 1.6.5.3, 1.6.5.4, 1.6.6.8
1.6.8.3 - 1.5.22.2, 1.5.22.3, 1.6.5.2, 1.6.5.3, 1.6.5.4, 1.6.6.8, 1.6.7.3
1.6.9.4 - 1.5.22.2, 1.5.22.3, 1.6.8.3, 1.6.9.3
1.6.10.6 - 1.6.9.4, 1.6.10.5
1.6.11.7 - 1.6.9.4, 1.6.10.6, 1.6.11.6
Получилось, что отставание на 24 версии. Но, если построить цепочку обновлений, то результат будет несколько иной.
Соответственно порядок обновлений будет следующий:
1.5.10.3
1.5.12.1
1.5.13.6
1.5.14.4
1.5.15.3
1.5.16.3
1.5.17.3
1.6.3.2
1.6.5.3
1.6.8.3
1.6.9.4
1.6.11.7
Итак, необходимо выполнить всего 12 обновлений.
После каждого обновления следует выполнять запуск в режиме "1С:Предприятие". В этом случае будут корректно выполнены процедуры, выполняющиеся после обновления и учитывающие изменения применяемых методик и объектов базы данных (план счетов, справочники, документы и т.д.).
Возникает резонный вопрос: "Почему бы не обновить сразу на последний релиз, используя файл поставки 1cv8.cf с партнерского диска ИТС или самостоятельно подготовленный файл поставки?". Конечно, попробовать можно, но здесь могут возникнуть 2 проблемы. Одна из них техническая. При большом объеме изменений и большом объеме базы данных после долгого и томительного ожидания обновление может закончиться ошибкой ОС, 1С или SQL сервера. Но это не главное. Основная проблема пропуска релизов заключается в том, что изменяются названия и количество реквизитов в регистрах, справочниках, документах. К сожалению, разработчики фирмы 1С активно изменяют состав метаданных. Давайте рассмотрим ситуацию с обновлением на отвлеченном примере. Итак...
Возможен такой гипотетический вариант. Первоначально конфигурация содержит справочник Контрагенты, в котором заполнен реквизит Адрес.
Версия 1. Справочник Контрагенты.
Имеется реквизит Адрес. Ну, и разумеется, он заполнен данными, которые очень нам нужны.
Версия 2. Справочник Контрагенты.
Изменения: Реквизит Адрес переименован в УдалитьАдрес. Добавлен регистр сведений КонтактнаяИнформация. Изменены все места конфигурации, в которых используется информация об адресе (Отчеты, печатные формы документов, форма элемента справочника Контрагенты и т.д.)
При запуске в режиме 1С:Предприятия 8 выполняется обновление, при котором данные из реквизита УдалитьАдрес переносятся в регистр сведений КонтактнаяИнформация.
Версия 3. Справочник Контрагенты.
Изменения: Удален реквизит УдалитьАдрес.
В результате если пропустить переход на версию 2, то потеряется вся информация об адресах. А при запуске в режиме "1С:Предприятия" обновление при попытке перенести данные из реквизита УдалитьАдрес в регистр сведений КонтактнаяИнформация выдаст ошибку - свойство объекта УдалитьАдрес не найдено.
При прыжке через 20 версий вероятность возникновения подобной ситуации резко возрастает.
Обновление через ключевые релизы
Можно ли как-то ещё сократить количество обновлений?
Да, можно. Для этого необходимо вычислить обязательные для запуска релизы (ключевые) и использовать файл обновления от текущего релиза до ключевого и т.д. Для УПП, например, ключевыми являются релизы 1.2.19.1, 1.2.23.2.
Использование подобной схемы позволяет избежать описанных выше ошибок и значительно сократить время обновления за счет сокращения количества обновлений.
Для обновления нам понадобится файл *.cfu или файл *.cf из дистрибутива поставщика. Подробнее о способах их получения можно почитать здесь.
Определение ключевых релизов
Для каждой базы данных ключевые релизы также будут разные. Определить, является ли релиз ключевым или нет, можно по двум признакам.
- Обновление на последующие версии конфигурации в обработке, которая запускается после обновления конфигурации, делается только с этого релиза.
Например, мы обнаружили, что в релизе 1.6.11.7 обработка перехода с версии на версию начинает работать только с релиза 1.6.2.39, тогда для нас ключевым становится релиз 1.6.3.2. И нам необходимо проверить, есть ли еще ключевые релизы в обработке обновления в релизе 1.6.3.2.
- При обновлении удаляются реквизиты или объекты в конфигурации, которые используются (заполнены) в базе данных.
Например, при обновлении мы обнаружили, что в релизе 1.6.8.3 удален регистр НДС_ВалютныйУчет. Чтобы принять решение, смотрим заполнение этого регистра в базе данных. Если регистр заполнен, то релиз 1.6.5.3 будет ключевым.
ВНИМАНИЕ! В данном случае номера релизов приведены только для облегчения понимания материала.
Следует также заметить, что в последнее время количество выявленных ключевых релизов заметно сократилось. А при регулярном обновлении подобные вопросы вообще не возникают.
опубликована 17.12.2008
редакция от 04.04.2013