← На главную

В процессе обновления платформ и конфигураций 1С часто возникает необходимость отказаться от использования устаревшего режима совместимости (например, с версии 8.3.6). Разберем, обязательно ли выполнять поэтапный переход с платформы на платформу (8.3.6 -> 8.3.7 -> 8.3.8 и т. д.), какие технические проблемы могут возникнуть при снятии совместимости и какова последовательность действий при выполнении этой процедуры.

Можно ли переключить режим совместимости напрямую?

Отвечая на главный вопрос: переходить через промежуточные версии режимов совместимости не обязательно. Если конфигурация своевременно обновляется, а собственные доработки не используют устаревший функционал платформы, можно сразу установить свойство режима совместимости в значение «Не использовать» (или выставить актуальную версию платформы).

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

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

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

1. Изменение работы и отображения управляемых форм. При переходе с режима 8.3.6 на 8.3.7 и выше существенно меняется логика компоновки элементов управляемого интерфейса (включая интерфейсы «Такси» и стандартный управляемый интерфейс 8.2). Некоторые элементы и формы могут изменить визуальное отображение или потребуют коррекции доработанных форм.
2. Запрет вызовов серверных функций при завершении работы. Начиная с определенных версий платформы действует строгое правило: Вызовы серверных функций при завершении работы запрещены. Если в обработчиках завершения работы системы (например, ПередЗавершениемРаботыСистемы) присутствуют прямые обращения к серверным процедурам и функциям, система вызовет ошибку выполнения.
3. Конфликт имен новых системных функций. С выходом новых релиза платформы в неё добавляются новые встроенные функции. Например, появление системной функции ПобитовоеНЕ может вызывать синтаксическую ошибку, если в конфигурации ранее уже была создана одноименная функция в модуле. В таком случае потребуется переименовать пользовательскую функцию или скорректировать обращения к ней.
4. Переход к асинхронным вызовам и отмена модальности. Отключение совместимости требует отказа от синхронных вызовов диалогов и модальных окон (таких как Предупреждение() или Вопрос()). Необходимо переходить на применение описаний оповещений и асинхронные методы.
5. Строгая проверка типов в запросах. Без режима совместимости оптимизатор СУБД жестче валидирует типы данных. Сравнения несравнимых типов или отсутствие явного приведения с помощью оператора ВЫРАЗИТЬ в полях составного типа могут привести к ошибкам выполнения запросов.
6. Совместимость с расширениями. Если в базе используются расширения конфигурации, режим совместимости каждого расширения не должен превышать режим совместимости основной конфигурации. После снятия режима в основной конфигурации потребуется скорректировать свойства всех подключенных расширений.

Пошаговый алгоритм отключения режима совместимости

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

1. Создание резервной копии. Выполним полную выгрузку информационной базы (файл .dt или средствами СУБД) до начала любых манипуляций.
2. Создание тестовой копии. Все изменения режима совместимости производим исключительно на тестовой базе.
3. Запуск проверки конфигурации. В режиме Конфигуратора откроем меню Конфигурация -> Проверка конфигурации. Включим флаги проверки синтаксиса, режимов выполнения и режима совместимости, чтобы заранее обнаружить синтаксические ошибки и устаревшие конструкции.
4. Изменение свойства конфигурации. В палитре свойств корневого элемента конфигурации найдем поле Режим совместимости и установим его в значение «Не использовать».
5. Применение изменений в монопольном режиме. Смена режима совместимости меняет физическую структуру хранения данных в СУБД. Категорически запрещено применять эти изменения через динамическое обновление! Обновление конфигурации базы данных следует проводить только в монопольном режиме.
6. Реструктуризация таблиц базы данных. После обновления конфигурации запустим процедуру Администрирование -> Тестирование и исправление, обязательно отметив пункт «Реструктуризация таблиц информационной базы». Это необходимо для корректного пересчета индексов и адаптации физических таблиц СУБД.
7. Комплексное тестирование. Проверим ключевые пользовательские сценарии: проведение документов, закрытие периода, запуск фоновых и регламентных заданий, а также корректность завершения работы клиентом.