← На главную

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

Механизм автовыбора версии и версионный редирект

Проанализируем архитектуру клиент-серверного взаимодействия. В отличие от файлового варианта работы, где за все операции отвечает исключительно локальный исполняемый файл платформы, клиент-серверный вариант предъявляет жесткие требования к совместимости компонентов.

Для корректного обмена данными между клиентом и кластером серверов 1С требуется полное совпадение версии релиза, вплоть до номера конкретной сборки (билда). Например, клиент версии 8.3.27.1606 не может взаимодействовать со службой кластера 8.3.24.1667 в рамках единого сеанса.

Рассмотрим подробнее, как именно отрабатывает платформа при попытке подключения:

1. Пользователь запускает исполняемый файл нужного релиза (например, 1cv8.exe из каталога новой версии 8.3.27.1606).
2. Клиентское приложение инициирует сетевое соединение с кластером серверов 1С и запрашивает параметры информационной базы.
3. В процессе рукопожатия клиент определяет точный номер сборки сервера 1С.
4. Если сервер сообщает, что работает на более старом релизе (например, 8.3.24.1667), запускающий процесс не выдает мгновенную ошибку, а обращается к механизму версионного редиректа.
5. Клиент опрашивает установленные на локальном компьютере версии платформы. Обнаружив подходящий релиз 8.3.24.1667, платформа в фоновом режиме порождает новый процесс из старого каталога bin, а исходный процесс закрывается.

Если бы старый релиз платформы был предварительно удален с клиентской машины, автозапуск не сработал бы, и система выдала бы штатное сообщение: «Несоответствие версий клиента и сервера 1С:Предприятия». Таким образом, обновление одного лишь клиентского рабочего места не переводит клиент-серверную базу на новый релиз.

Опасность формата .dt и почему база оказалась пустой

Выясним причину, по которой информационная база в Конфигураторе стала пустой после неудачной попытки развертывания. Механизм выгрузки и загрузки через файл с расширением .dt предназначен в первую очередь для миграции между различными СУБД (например, при переходе с файлового режима на PostgreSQL или Microsoft SQL Server) либо для создания копий небольших баз.

Важно помнить, что процедура «Загрузить информационную базу» не является транзакционной операцией восстановления СУБД. Алгоритм ее работы устроен следующим образом:

1. Конфигуратор монопольно блокирует базу данных.
2. Платформа полностью очищает таблицы текущей базы в СУБД.
3. Начинается чтение архива и создание структуры метаданных и таблиц заново.

Если процедура прерывается на начальном этапе из-за несоответствия требований платформы к конфигурации, база остается в промежуточном состоянии — старые таблицы уже удалены, а новые еще не созданы. Поэтому для СУБД PostgreSQL штатным и надежным методом создания резервных копий является использование консольных утилит pg_dump и pg_restore.

Обходные пути решения без участия администратора сервера

Если администратор сервера временно недоступен, а приступить к работе с конфигурацией или данными из архива .dt требуется немедленно, рассмотрим альтернативные варианты развертывания.

1. Развертывание во временную файловую базу. Создадим на локальном диске пустую файловую базу с помощью новой платформы 8.3.27. Так как в файловом режиме серверная часть отсутствует, версионного редиректа не произойдет. Запустим Конфигуратор новой версии и выполним загрузку файла .dt. Это позволит сразу получить доступ к метаданным и коду.
2. Временная публикация через веб-сервер. Если требуется организовать работу нескольких пользователей с полученной файловой базой, ее можно опубликовать на локальном веб-сервере (Apache или IIS). Для этого в Конфигураторе файловой базы 8.3.27 перейдем в меню «Администрирование» — «Публикация на веб-сервере...». Подключение остальных пользователей будет осуществляться через тонкий клиент или веб-браузер без задействования кластера серверов 1С.

Параллельная работа нескольких служб сервера 1С

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

Для развертывания параллельного кластера администратор выполняет следующие действия:

1. Устанавливает серверную часть релиза 8.3.27 на сервер.
2. Регистрирует отдельную службу агента сервера ragent с уникальным именем, выделив ей собственный каталог данных с помощью параметра -d.
3. Назначает для нового кластера свободный пул сетевых портов, отличный от стандартного диапазона (например, порты 2540, 2541, 2560–2591 вместо стандартных 1540, 1541, 1560–1591).
4. Создает новую информационную базу в консоли управления сервером 8.3.27 и загружает подготовленный файл .dt.

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