В мире 1С часто возникают споры о том, насколько гибкой является архитектура системы. Один из самых частых вопросов, который может стоить системному администратору или программисту не только рабочего времени, но и проигранного спора — это вопрос совместимости версий клиента и сервера. Рассмотрим ситуацию: можно ли установить новую платформу 8.3.19 на терминальный сервер и подключиться к базе, если сервер приложений 1С продолжает работать на версии 8.3.12? Проанализируем технические аспекты и выясним, почему «магии» не произойдет.
Разберем основной технический барьер. Главная причина, по которой клиент 8.3.19 не может взаимодействовать с сервером 8.3.12, заключается в бинарном протоколе обмена данными. При каждом изменении даже минорной версии платформы 1С (вторая или третья цифра в номере), разработчики часто меняют структуру сетевых пакетов, которыми обмениваются клиентское приложение и процессы сервера rphost.
Если версии не совпадают до последней цифры, клиент просто не сможет десериализовать данные, полученные от сервера, и наоборот. В момент попытки авторизации происходит проверка версии, и если обнаруживается различие, система мгновенно выдает ошибку: «Несоответствие версий клиента и сервера 1С:Предприятие 8». Важно понимать, что для прямого подключения через тонкий или толстый клиент исключений не существует.
Проанализируем ситуацию с точки зрения архитектуры кластера. Каждый релиз платформы имеет:
Рассмотрим единственный сценарий, когда мы можем работать с базой на платформе 8.3.12, фактически не запуская клиент этой версии на своем компьютере. Это использование веб-клиента.
Если на сервере 8.3.12 настроена публикация базы на веб-сервере (например, Apache или IIS), пользователь может зайти в базу через обычный браузер (Chrome, Firefox, Safari). В этом случае пользователю вообще не нужна установленная платформа 1С на терминале или локальном ПК. Однако это не означает, что клиент 8.3.19 «заработал» с сервером 8.3.12. Это означает, что веб-интерфейс, написанный на JavaScript, транслирует команды серверу через расширение веб-сервера, которое обязательно соответствует версии сервера (8.3.12).
Выясним причину, по которой некоторые пользователи ошибочно полагают, что у них «запускаются разные версии». В платформе реализован механизм, который может сбить с толку. В настройках списка баз можно указать параметр «Версия платформы».
Если на компьютере пользователя установлены обе версии — и 8.3.12, и 8.3.19, то программа запуска 1cestart.exe сама определит, какая версия сервера у базы, и автоматически выберет нужный исполняемый файл для запуска. Если же на терминале стоит только 8.3.19, а сервер требует 8.3.12, запуск прервется ошибкой.
Если вы все же решите обновить сервер приложений до 8.3.19, чтобы он соответствовал клиенту, важно учитывать критические изменения в структуре данных. Начиная с версии 8.3.15 и выше, формат хранения данных внутри SQL или файловой базы существенно меняется.
Внимание! При первом же открытии базы более новой платформой 1С предложит обновить структуру базы данных. Если вы согласитесь, вернуться на платформу 8.3.12 без восстановления из бэкапа будет невозможно. Старая платформа выдаст ошибку «Неверный формат хранилища данных».
Если ситуация требует одновременной работы старых баз на 8.3.12 и новых на 8.3.19, необходимо развернуть два параллельных кластера. Разберем по шагам, как это сделать:
1C:Enterprise 8.3.19 Server Agent).ИмяСервера:1641.Пример регистрации службы для новой версии платформы (в повелительном наклонении для командной строки):
"C:\Program Files\1cv8\8.3.19.XXXX\bin\ragent.exe" -instsrvc -usr ".\1C_Service_User" -pwd "password" -port 1640 -regport 1641 -range 1660:1691 -d "C:\Program Files\1cv8\srvinfo_8_3_19"
Посмотрим на результат нашего анализа: попытка запустить клиент 8.3.19 напрямую к серверу 8.3.12 без обновления последнего обречена на провал. Режим совместимости конфигурации (даже если у вас старая Бухгалтерия 2.0) влияет только на поведение встроенного языка и запросов внутри базы, но не меняет протокол связи между приложением-клиентом и сервером. Поэтому, чтобы не проигрывать споры и не останавливать работу предприятия, всегда обеспечивайте полное соответствие версий платформы в рамках одного кластера.