Ситуация, когда базу данных 1С версии 8.2 случайно открывают и сохраняют в конфигураторе современной платформы (например, 8.3.27), встречается довольно часто. Это приводит к так называемому "отравлению" структуры базы данных: платформа 8.3 автоматически модифицирует системные таблицы, после чего платформа 8.2 перестает понимать формат базы, выдавая критическую ошибку SDBL: Поле или вложенная таблица с именем Language повторяется в таблицах STTModelsDesc.Descr, STTModelsDesc.Acoustic. В этой статье мы подробно разберем, почему это происходит и как вернуть работоспособность базы на старой платформе.
Проанализируем техническую сторону вопроса, изучив, как устроена структура хранения базы данных. Начиная с последних релизов платформы 8.3 (в частности, ветки 8.3.23 и выше), компания 1С интегрировала механизмы распознавания речи (Speech-To-Text). Для хранения моделей и настроек этого механизма в структуру любой базы данных, открытой в режиме "Конфигуратор", автоматически добавляются системные таблицы группы STTModels (Acoustic, Descr, Grammars и другие).
Проблема заключается в том, что внутренняя логика хранения описания этих таблиц в системном объекте DBSchema (схема базы данных) в версии 8.3 стала несовместима с парсером SDBL старой платформы 8.2. Когда платформа 8.2 пытается прочитать DBSchema, она натыкается на описание полей Language в новых таблицах и ошибочно интерпретирует их как дублирующие, так как не умеет корректно обрабатывать новый формат вложенных таблиц метаданных. Простое удаление этих таблиц из SQL-базы или попытка "лечения" через chdbfl.exe не помогают, так как описание проблемы зашито глубоко в системных данных самой конфигурации.
Рассмотрим самый эффективный метод, если у вас сохранилась архивная копия базы (даже если она старая). Нам не нужно полностью восстанавливать старый бэкап и терять данные, нам нужно только "забрать" из него правильную структуру метаданных, которую понимает 8.2.
Проделаем следующие шаги:
DBSchema, Params и Config. В случае использования SQL-версии, эти таблицы можно перенести с помощью SQL-запросов.DBSchema) и саму конфигурацию на те, что были созданы платформой 8.2.STTModels, которые теперь не описаны в DBSchema, и удалит их как мусорные. На этом этапе также может быть полезна универсальная очистка базы от накопившихся неактуальных данных.Разберем ситуацию, когда база находится на MS SQL Server и вы готовы к ручным правкам системных данных. Этот метод требует осторожности, так как работа идет напрямую с таблицами 1С.
Проанализируем последовательность действий:
DBSchema. Это единственная таблица, хранящая двоичные данные о структуре всей базы.STTModels. Если у нас есть пустая база, созданная на 8.2, мы можем попробовать заменить содержимое таблицы DBSchema в испорченной базе на содержимое аналогичной таблицы из пустой базы 8.2.DBSchema должна соответствовать реальному составу метаданных. Поэтому после такой замены база может не открыться в режиме "Предприятие", но она позволит зайти в Конфигуратор..cf), который точно не открывался в 8.3, и выполним обновление конфигурации базы данных.Если манипуляции с системными таблицами кажутся слишком рискованными, рассмотрим наиболее надежный, хоть и трудоемкий способ — полный перенос данных в чистую базу или настройка интеграции, используя обмены через брокеры — поможет универсальный обмен данными через COM-соединение.
Посмотрим на алгоритм действий:
.cf), которая была сохранена до инцидента. Если такой нет, попробуйте выгрузить конфигурацию из текущей базы в 8.3, но велика вероятность, что 8.2 не примет этот файл из-за разницы версий метаданных. В этом случае придется вручную перенести изменения в чистую базу 8.2.STTModels и ошибки SDBL не будут влиять на процесс.Автор темы упоминал, что в 8.3 перестали работать внешние компоненты (DLL). Разберем, почему это происходит, если вы все же решите остаться на новой платформе:
Во-первых, проверьте разрядность клиента. Если ваши DLL 32-битные (x86), они никогда не заработают под 64-битным клиентом 8.3. Нужно принудительно устанавливать и запускать 32-битную версию платформы.
Во-вторых, современные версии 8.3 имеют жесткие настройки безопасности. Для работы старых компонент проанализируем файл conf.cfg. В нем может потребоваться добавить параметр, отключающий проверку безопасности для расширений и компонент:
DisableExtensionPrecedenceRule=-1
SafeModeSettings=0
В-третьих, в платформе 8.3 изменился механизм защиты памяти. Если компонента очень старая, она может вызывать исключение доступа к памяти. В этом случае поможет только запуск 1С в режиме совместимости с DEP (Data Execution Prevention) или добавление 1cv8.exe в исключения системы предотвращения выполнения данных Windows.
Как отметил автор, реструктуризация необходима для очистки базы от старых данных. При ошибке SDBL реструктуризация — это первое, что ломается. Помните, что Ошибка SDBL: Поле Language повторяется — это не порча ваших данных, а неспособность старой платформы прочитать новые системные поля. Следуя приведенным выше методам подмены DBSchema или переноса данных через XML, вы сможете вернуть базу в рабочее состояние под управлением 8.2.19.130.