В практике администрирования и разработки 1С часто возникает классическая дилемма: разработчик пытается решить инфраструктурную проблему клиента за счет грубого вмешательства в метаданные типовой конфигурации. Типичный сценарий — необходимость запустить современную конфигурацию, рассчитанную на режим совместимости 8.3.14, на более старой версии платформы (например, 8.3.12), так как клиент по разным причинам отказывается обновлять серверное или клиентское окружение.
В данной статье мы подробно рассмотрим, как технически сделать поле «Режим совместимости» доступным для редактирования без полной потери поддержки, проанализируем критические риски такого решения (на примере БСП и расширений) и разберем правильные альтернативные пути выхода из этой ситуации.
При попытке изменить режим совместимости в свойствах конфигурации разработчики часто сталкиваются с тем, что это поле заблокировано (отображается серым цветом), даже если в настройках поддержки включена возможность редактирования («Редактируется с сохранением поддержки»).
Выясним причину этого поведения платформы. По умолчанию, когда мы включаем возможность изменения конфигурации, правила редактирования применяются к дочерним объектам метаданных (справочникам, документам, обработкам), но сам корневой узел конфигурации остается в режиме «Не редактируется».
Разберем по шагам, как разблокировать свойства корневого узла:
После выполнения этих действий корневые свойства конфигурации в палитре свойств (включая имя, синоним, версию и, самое главное, Режим совместимости) станут доступны для изменения. Теперь мы можем физически выбрать в выпадающем списке значение Версия 8.3.12 вместо Версия 8.3.14.
Однако то, что платформа позволяет технически изменить это свойство, вовсе не означает, что конфигурация после этого будет корректно работать. Рассмотрим критические проблемы, которые гарантированно возникнут при попытке «понизить» режим совместимости.
Современные типовые конфигурации построены на базе Библиотеки стандартных подсистем (БСП) версии 3.1 и выше. Попытка принудительно запустить БСП 3.1 в режиме совместимости 8.3.12 приведет к полной неработоспособности системы по нескольким причинам.
Во-первых, разработчики БСП используют программный контроль среды. В общем модуле СтандартныеПодсистемыСервер реализована жесткая проверка версии платформы и режима совместимости при запуске системы. Если запустить код в режиме ниже заявленного, сработает защита, которая выбросит системное исключение, и пользователь увидит критическую ошибку:
// Пример логики проверки совместимости в БСП
Если ОбщегоНазначенияКлиентСервер.РежимСовместимостиПлатформы() < КодВерсииПлатформы.V8_3_14 Тогда
ВызватьИсключение НСтр("ru = 'Запуск системы с текущим режимом совместимости не поддерживается!'");
КонецЕсли;
Во-вторых, в коде БСП 3.1 активно задействованы механизмы платформы, появившиеся только в версии 8.3.14. К ним относятся новые методы работы с фоновыми заданиями, расширенные возможности сериализации данных в XML/JSON, новые свойства объектов метаданных (например, характеристики регистров накопления) и специфические механизмы работы с HTTP-запросами. Попытка компиляции этого кода на старой платформе или в старом режиме совместимости вызовет множественные синтаксические ошибки, которые разработчику придется «выкусывать» вручную, полностью лишая себя возможности автоматического обновления в будущем.
Понижение режима совместимости влечет за собой серьезные изменения в структуре базы данных СУБД при реструктуризации. Платформа 1С при режиме совместимости 8.3.14 использует оптимизированные механизмы хранения индексов и таблиц.
При попытке сохранить конфигурацию с пониженным режимом совместимости на уровне СУБД начнется процесс реструктуризации таблиц. В этот момент крайне высок риск получить критическую ошибку «Ошибка формата потока». Это связано с тем, что конфигуратор старой версии или старый режим совместимости физически не могут корректно преобразовать структуру новых объектов метаданных, сохраненную в более современном формате.
Современные базы данных редко обходятся без расширений конфигурации. Платформа 1С жестко контролирует соответствие режимов совместимости основной конфигурации и подключенных к ней расширений.
Действует строгое правило: режим совместимости расширения не должен быть выше режима совместимости основной конфигурации. Если мы принудительно понизим режим основной конфигурации до 8.3.12, а у подключенных расширений (включая типовые патчи от фирмы «1С» или кастомные доработки) останется режим 8.3.14, платформа заблокирует запуск базы данных со следующей ошибкой:
Значение контролируемого свойства РежимСовместимости у объекта не совпадает со значением в расширяемой конфигурации.
Вам придется вручную открывать каждое расширение и понижать его режим совместимости. При этом, если расширение использует современные возможности платформы (например, собственные регистры или временные таблицы в запросах расширений, которые требуют определенной версии совместимости), эти расширения просто откажутся работать.
Проанализируем реальную причину, по которой системные администраторы клиента могут отказываться от обновления платформы. Часто это связано не с ленью, а с использованием устаревших библиотек ActiveX или COM-объектов.
Многие драйверы торгового оборудования (весы, принтеры этикеток, сканеры штрихкодов, ТСД) были написаны много лет назад и существуют только в виде 32-разрядных (x86) библиотек. При переходе на современные версии платформы 1С часто обновляют и разрядность клиентских приложений на 64-бит (x64), так как они работают стабильнее и быстрее распределяют память. Однако 64-битный процесс тонкого или толстого клиента 1С физически не может загрузить 32-битную DLL-библиотеку через ActiveX.
В результате у клиента после обновления платформы полностью «отваливается» торговое оборудование, работающее через старые COM-драйверы. Именно поэтому администраторы настаивают на сохранении старых версий платформы (например, 8.3.12).
Вместо того чтобы «калечить» метаданные конфигурации, снимать корневой узел с поддержки и обрекать себя на мучительные ручные обновления, мы рекомендуем решить проблему на уровне ИТ-инфраструктуры.
Рассмотрим два правильных сценария:
ActiveX для торгового оборудования, нет никакой необходимости оставаться на старой платформе 8.3.12. Установите клиенту современную версию платформы (например, актуальный релиз ветки 8.3.22 или выше), но выберите при установке именно 32-разрядный (x86) тонкий/толстый клиент. Он без проблем инициализирует все старые библиотеки и драйверы торгового оборудования, при этом обеспечивая полную совместимость с требованиями конфигурации.Таким образом, изменение режима совместимости «вниз» в типовой конфигурации — это тупиковый путь, ведущий к потере поддержки, риску разрушения базы данных и невозможности использования современных расширений. Решайте подобные задачи исключительно архитектурными методами на уровне платформы и инфраструктуры.