Переход на новые версии платформы «1С:Предприятие» часто сопровождается необходимостью изменения режима совместимости конфигурации. Однако начиная с версии 8.3.12, этот процесс перестал быть просто переключением флажка в свойствах. В данной статье мы детально проанализируем ситуацию, когда после установки режима совместимости «Не использовать» база данных перестает запускаться, выдает ошибки SDBL и блокирует любые попытки возврата к исходному состоянию. Мы разберем причины возникновения этих проблем и выработаем алгоритм их решения.
Рассмотрим, что происходит «под капотом» платформы при переключении режима совместимости на 8.3.12. До этой версии расширения практически не влияли на физическую структуру таблиц основной базы данных. Начиная с 8.3.12, архитектура была кардинально пересмотрена. Теперь расширения могут создавать собственные таблицы и полноценно участвовать в реструктуризации.
Как только мы устанавливаем режим «Не использовать» (что фактически означает использование стандартов версии 8.3.12 и выше), платформа инициирует необратимый процесс переноса метаданных расширений в новые системные таблицы. Проанализируем последствия: если в расширении есть хотя бы один заимствованный объект (даже просто форма), платформа помечает структуру базы как измененную по стандартам 8.3.12. Именно поэтому при попытке вернуть режим 8.3.10 мы получаем сообщение: «Невозможно включить режим совместимости при наличии изменений структуры данных расширениями конфигурации». Платформа просто не умеет «откатывать» таблицы расширений к старому формату.
Выясним причину ошибки «Режим совместимости конфигурации с 1С:Предприятием версии 8.3.12 не поддерживается». Важно понимать, что это сообщение генерирует не сама платформа, а программный код БСП, на которой построена «Бухгалтерия КОРП» и другие типовые решения.
Разберем, где именно это происходит. В типовых конфигурациях существует общий модуль СтандартныеПодсистемыСервер, в котором выполняется проверка текущего режима совместимости при запуске системы. Разработчики типовых решений ограничивают список допустимых режимов теми версиями, на которых конфигурация прошла полное тестирование.
Для исправления этой ситуации на этапе разработки мы можем временно модифицировать код. Рассмотрим пример того, как расширить список допустимых версий:
// В общем модуле СтандартныеПодсистемыСервер находим процедуру ПередЗапускомПрограммы
// Или специализированную функцию проверки режима совместимости
Процедура ПроверитьРежимСовместимости() Экспорт
ДопустимыеРежимы = Новый Массив;
ДопустимыеРежимы.Добавить("Версия8_3_10");
// Добавляем поддержку режима "Не использовать" (текущая версия платформы)
ДопустимыеРежимы.Добавить("Версия8_3_12");
// ... дальнейшая логика проверки
КонецПроцедуры
Применим «уличную магию», как выразились участники форума: если мы добавим нужную версию в массив допустимых, проверка БСП будет пройдена, и предприятие запустится. Однако помните, что это лишь способ «зайти» в базу, чтобы исправить последствия на уровне данных.
Проанализируем самую сложную проблему: Ошибка SDBL: Некорректное использование LOCAL/GLOBAL в SET GENERATION. Эта ошибка возникает при попытке системы обновить счетчики (генераторы) идентификаторов в таблицах SQL-сервера. Выясним, почему это происходит: в платформе 8.3.12 существовал зарегистрированный баг (номер 10197605), связанный с некорректной работой планов видов характеристик (ПВХ) и реквизитов обобщенного типа в расширениях.
Если ваше расширение заимствует ПланВидовХарактеристик, платформа при реструктуризации может повредить внутренние связи в системных таблицах. В этом случае расширение невозможно ни обновить, ни удалить, ни отключить. Любая попытка приводит к критической ошибке и закрытию конфигуратора.
Первым делом проверим версию используемой платформы. Проблема с SET GENERATION официально признана исправленной в версии 8.3.12.1616 и выше. Посмотрим на алгоритм действий:
В большинстве случаев обновление платформы позволяет корректно завершить реструктуризацию, которую не смогла выполнить старая версия.
Если обновление платформы не помогает, попробуем «обмануть» систему, уменьшая объем метаданных, подлежащих реструктуризации. Проанализируем этот путь:
SDBL, значит, именно он является «токсичным» для структуры БД.Как только нам удастся очистить расширение от всех заимствованных объектов, само расширение можно будет успешно удалить из списка.
Рассмотрим ситуацию, когда автор пытался очистить таблицы Config и ConfigSave. Этого недостаточно, так как информация о расширениях в 8.3.12+ разнесена по нескольким системным таблицам. Посмотрим на их список:
Extensions — общие сведения о подключенных расширениях.ExtensionFiles — хранилище самих файлов .cfe.ExtensionsInfo — информация о состоянии применения расширений к конкретной базе.Внимание! Прямое редактирование таблиц SQL крайне не рекомендуется и может лишить вас поддержки вендора. Однако в критических ситуациях, если база не запускается, специалисты прибегают к очистке этих таблиц вместе с Config, чтобы «забыть» о существовании расширения. После этого обязательно требуется выполнение Тестирования и исправления с включенными галками «Реиндексация» и «Проверка логической целостности».
Если структура базы данных окончательно повреждена и конфигуратор выдает ошибку «Нарушена целостность», рассмотрим наиболее надежный, хоть и трудоемкий метод — перенос данных.
Разберем шаги этого процесса:
Универсальный обмен данными в формате XML, предварительно выгрузив правила обмена из самой конфигурации.Подводя итог, отметим, что отключение режима совместимости в версии 8.3.12 при наличии расширений — это операция с высоким уровнем риска. Платформа производит глубокую реструктуризацию, которая часто конфликтует с программными проверками в БСП.
Основные правила для избежания подобных ситуаций:
SDBL.Если вы уже столкнулись с проблемой, начните с обновления платформы и корректировки кода БСП в общем модуле. Это самый быстрый способ вернуть систему к жизни без потери данных.