Вопрос совмещения различных версий платформы 1С в рамках одной распределенной информационной базы (РИБ) часто возникает при миграции крупных систем или при наличии парка устаревшего оборудования на удаленных точках. Ситуация, когда центральный узел уже переведен на 1С:Предприятие 8.3, а периферийные базы остаются на 8.2, технически реализуема, но требует глубокого понимания внутренних механизмов платформы. Разберем эту ситуацию подробно, проанализируем риски и определим последовательность действий для обеспечения стабильного обмена.
Первое и самое важное, что мы должны рассмотреть, — это свойство конфигурации РежимСовместимости. Именно оно определяет, как платформа будет интерпретировать код и структуры данных. Если мы переводим центральную базу на платформу 8.3, но при этом оставляем в свойствах конфигурации значение Режим совместимости равным "Версия 8.2.13" или "Версия 8.2.16", то периферийная база, работающая на платформе 8.2, сможет корректно открывать конфигурацию и выполнять программный код.
Проанализируем последствия изменения этого режима. Если вы решите "поднять" режим совместимости до 8.3.х в центральном узле, то при попытке загрузить обновление конфигурации в периферийную базу (которая работает на платформе 8.2), система выдаст критическую ошибку. Платформа 8.2 физически не умеет работать с объектами и свойствами, появившимися в версиях 8.3. Поэтому жесткое сохранение режима совместимости является обязательным условием для существования такого "зоопарка" версий.
Обмен в РИБ строится на формировании и чтении XML-файлов. Рассмотрим подробнее процесс сериализации объектов (документов, справочников, регистров). Платформа 8.3 использует обновленные алгоритмы записи данных в XML. Даже если режим совместимости включен, существуют нюансы в представлении некоторых типов данных.
Выясним причину возможных сбоев при обмене:
На практике это означает, что "обмен работает без проблем" — утверждение верное лишь до определенного момента. Любое обновление метаданных, затрагивающее состав плана обмена, может привести к тому, что файлы обмена перестанут восприниматься принимающей стороной.
Существует устойчивое мнение, что платформа 8.3 более требовательна к ресурсам. Проанализируем ситуацию объективно. Сама по себе платформа (ядро) версии 8.3 работает с памятью не менее эффективно, чем 8.2. Основные "тормоза", на которые жалуются пользователи, связаны с двумя факторами:
Во-первых, это интерфейс "Такси". Он действительно потребляет больше видеопамяти и ресурсов процессора для отрисовки графических элементов. Однако, если конфигурация остается на обычных формах (что типично при использовании режима совместимости с 8.2), разница в скорости отрисовки будет минимальной.
Во-вторых, это использование Библиотеки стандартных подсистем (БСП). Современные версии БСП, рассчитанные на платформу 8.3, выполняют огромное количество фоновых заданий и проверок, что и замедляет работу на слабом железе. Если же мы просто запускаем старую конфигурацию Управление торговлей 10.3 на платформе 8.3, она может работать даже быстрее за счет оптимизации работы с SQL-запросами и индексами в новом ядре.
Разберем важный нюанс, касающийся файловых баз данных. Начиная с версии 8.3.8, 1С представила новый формат файловой базы с возможностью выбора размера страницы (до 64 Кб). Платформа 8.2 работает только со старым форматом (размер страницы 4 Кб). Если при переходе на 8.3 в центральной базе будет произведена конвертация формата базы данных или изменение размера страницы, вы не сможете использовать этот файл базы на компьютерах с платформой 8.2. Поэтому при миграции важно сохранять старый формат хранения данных для обеспечения совместимости на уровне файловой системы.
Иногда препятствием становится не сама платформа, а код внутри конфигурации. Посмотрим на пример типичной проверки, которая может встретиться в модуле приложения или в процедурах обмена БСП:
Если СистемнаяИнформация.ВерсияПриложения < "8.3.10" Тогда
ВызватьИсключение "Для работы данной функции требуется платформа версии не ниже 8.3.10";
КонецЕсли;
В случае РИБ такие проверки могут быть "зашиты" в механизмы выгрузки данных. Перед тем как переводить центральный узел на 8.3, необходимо провести глобальный поиск по конфигурации на предмет жестких проверок ВерсияПриложения или ВерсияПлатформы, чтобы убедиться, что периферийные узлы не "отвалятся" по программным причинам.
Рассмотрим пошаговый алгоритм действий, если вы все же решили оставить часть узлов на старой платформе:
Запрос или МенеджерВременныхТаблиц могут приводить к разным остаткам.regsvr32 comcntr.dll из соответствующих папок bin.Подведем итог: работа РИБ на разных релизах — это жизнеспособная, но временная схема. Мы рекомендуем использовать её только как переходный этап. Для постоянной эксплуатации крайне желательно унифицировать парк ПО, так как риски внезапной остановки обмена из-за несовместимости сериализации данных могут перевесить выгоду от экономии на обновлении компьютеров.