← На главную

При обслуживании информационных баз 1С часто возникает вопрос: обязательно ли выполнять последовательную установку промежуточных релизов платформы или можно сразу установить актуальную сборку? Разберем ключевые отличия обновления платформы от обновления конфигурации, проанализируем возможные риски и пошагово рассмотрим процесс безопасного перехода.

Принципиальное отличие обновления платформы от обновления конфигураций

В экосистеме 1С:Предприятие действуют разные правила для прикладных решений и технологической платформы:

1. Релизы конфигураций (прикладных решений, таких как Бухгалтерия предприятия, ERP или ЗУП) требуют строго последовательного обновления. Каждый релиз содержит свои обработчики обновления данных, которые должны выполниться по цепочке.
2. Технологическая платформа — это среда исполнения. Ее можно и нужно обновлять сразу с устаревшей версии (например, 8.3.8.2167) на самый актуальный стабильный релиз ветки 8.3, минуя установку промежуточных сборок.

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

Возможные риски и технические особенности при резком обновлении

Проанализируем ключевые факторы, способные повлиять на работоспособность системы при переходе с устаревших версий:

1. Формат таблиц базы данных: При первом открытии базы в новой платформе может выполниться реструктуризация таблиц. В файловом режиме файл базы данных 1Cv8.1CD может быть преобразован в более современный формат, после чего открыть его старой платформой без предварительной выгрузки будет невозможно.
2. Клиент-серверный режим и СУБД: В клиент-серверном варианте версии платформы на сервере 1С и всех рабочих станциях пользователей должны строго совпадать. Кроме того, современные релизы платформы могут не поддерживать устаревшие версии СУБД (например, ранние версии Microsoft SQL Server или старые сборки PostgreSQL без специализированных патчей).
3. Лицензирование: В современных версиях платформы изменен механизм сбора сведений о конфигурации оборудования и виртуализации. При значительном скачке версий может потребоваться повторная активация программной лицензии с использованием резервного пин-кода. Для аппаратных ключей защиты может потребоваться обновление драйвера HASP Device Driver.
4. Публикация на веб-сервере: Если база используется через браузер, мобильные клиенты или веб-сервисы, после установки платформы необходимо заново выполнить публикацию информационной базы на веб-сервере (IIS или Apache) через Конфигуратор или утилиту webinst, чтобы обновить модуль расширения wsisapi.dll или mod_1cws.so.
5. Разрядность и внешние компоненты: Если ранее использовалась 32-разрядная платформа, а новая устанавливается в 64-битном варианте, все внешние компоненты (драйверы торгового оборудования, криптопровайдеры) должны быть совместимы с 64-битной архитектурой.

Пошаговый план безопасного перехода на новую платформу

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

1. Создание полной резервной копии: До установки любых обновлений обязательно создаем архивную копию базы данных. В файловом режиме копируем файл 1Cv8.1CD при отключенных пользователях либо делаем выгрузку через Конфигуратор в файл с расширением .dt (пункт меню Администрирование → Выгрузить информационную базу). В клиент-серверном режиме создаем резервную копию средствами самой СУБД.
2. Сохранение старой платформы: Не удаляйте предыдущую версию платформы (в нашем примере 8.3.8.2167) перед установкой новой. Платформы разных версий могут быть установлены на одном компьютере параллельно. Это позволит при необходимости быстро запустить базу на старой версии.
3. Установка актуального релиза: Устанавливаем целевой релиз платформы на сервер и рабочие станции.
4. Тестовый запуск и реструктуризация: Запускаем Конфигуратор от имени администратора. При запросе подтверждения реструктуризации соглашаемся на выполнение операции. После успешного входа в Конфигуратор проверяем запуск базы в режиме 1С:Предприятие.
5. Очистка локального кэша: При возникновении интерфейсных сбоев или ошибок динамического обновления очищаем каталоги временных файлов пользователя (каталоги AppData\Local\1C\1cv8 и AppData\Roaming\1C\1cv8).
6. Окончательный ввод в эксплуатацию: После проверки корректности проведения документов, отчетов и интеграций предоставляем доступ пользователям. Старую версию платформы можно удалить через стандартную панель управления после нескольких дней стабильной работы.