Как исправить ошибку SDBL с дублированием поля Language в таблицах STTModelsDesc при переходе между версиями платформы 1С?

При работе с платформой 1С:Предприятие 8.3 программисты и системные администраторы часто сталкиваются с ситуацией, когда информационную базу необходимо перенести между разными релизами платформы. Одной из наиболее специфических и труднодиагностируемых проблем последнего времени стала ошибка SDBL, связанная с повторяющимися именами Language в таблицах STTModelsDesc.Descr и STTModelsDescs.Acoustic. Эта проблема обычно возникает в сценарии, когда база была открыта в современной версии платформы (например, 8.3.23 или 8.3.26), а затем её попытались вернуть или загрузить в более старый релиз (например, 8.3.8 или 8.3.10).

В данной статье мы подробно разберем, почему возникает этот конфликт, как устроены внутренние механизмы хранения данных в 1С и какие шаги необходимо предпринять для восстановления работоспособности базы данных.

Выясним причину возникновения ошибки

Для начала проанализируем ситуацию с точки зрения архитектуры платформы. Начиная с версии 8.3.23, компания «1С» интегрировала в платформу механизмы распознавания речи (Speech-to-Text, или STT). Для поддержки этой функциональности на уровне системы управления базами данных (СУБД) платформа автоматически создает служебные таблицы. К ним относятся _STTModelsDesc и _STTModelsDescs.

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

Когда мы пытаемся открыть такую «обновленную» базу старым релизом платформы (например, 8.3.8), её внутренний движок SDBL (Simple Data Base Layer) натыкается на структуру, которую он не понимает. С точки зрения старого движка, наличие определенных полей в этих системных таблицах выглядит как дублирование или нарушение схемы данных, что и приводит к критической ошибке при попытке выгрузки или загрузки файла .dt.

Способ 1: Реструктуризация через «Тестирование и исправление» (Файловый и серверный варианты)

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

Выполним следующие шаги:

1. Запустим информационную базу в режиме Конфигуратора, используя новую версию платформы (ту, которая вызвала изменения, например, 8.3.23.1997 или выше).
2. Перейдем в меню Администрирование — Тестирование и исправление....
3. В появившемся окне выберем только один пункт: Реструктуризация таблиц информационной базы.
4. Нажмем кнопку Выполнить. Дождемся завершения процесса. Обратите внимание, что на больших базах этот процесс может занять значительное время.
5. После успешного завершения реструктуризации закроем конфигуратор.

Как показывает практика, после этой процедуры системные таблицы STT корректно инициализируются, и база начинает открываться в старых релизах (8.3.8, 8.3.10), а ошибка SDBL при выгрузке .dt исчезает. Если база файловая, рекомендуем также выполнить сжатие таблиц, так как после реструктуризации размер файла 1Cv8.1CD может временно увеличиться.

Способ 2: Изменение режима совместимости

Если первый способ не помог, проанализируем настройки самой конфигурации. Иногда ошибка вызвана тем, что платформа застряла между состояниями разных режимов совместимости. Рассмотрим алгоритм действий:

1. Откроем конфигурацию в актуальной версии платформы.
2. В свойствах корня конфигурации временно поднимем Режим совместимости (например, с 8.1 до 8.2 или с 8.3.8 до 8.3.10).
3. Применим изменения (клавиша F7), согласившись на реструктуризацию.
4. Вернем режим совместимости обратно на требуемый уровень.
5. Снова применим изменения.

Этот метод заставляет платформу полностью пересобрать внутреннюю схему DBSchema, что часто устраняет фантомные дубли полей в системных таблицах.

Способ 3: Восстановление через SQL (для опытных администраторов)

В случае работы с клиент-серверным вариантом на MS SQL Server или PostgreSQL, когда база имеет огромный объем и запуск полной реструктуризации невозможен из-за длительного простоя (например, более 48 часов), можно прибегнуть к прямому редактированию системных таблиц. Внимание: этот метод является недокументированным и требует наличия свежего бэкапа!

Проанализируем логику решения: ошибка возникает из-за несовпадения описания в таблице DBSchema и физического наличия таблиц _STT*.

Алгоритм действий в консоли запросов SQL:

1. Если у вас есть копия базы, сделанная до сбоя (до открытия новой платформой), можно попробовать перенести содержимое таблицы DBSchema из «здоровой» базы в «больную».
2. Физически удалим из базы данных таблицы, начинающиеся на _STT. В SQL это делается командой DROP TABLE.
3. После этого запустим конфигуратор старой версии платформы. Система может потребовать выполнить реструктуризацию — соглашаемся. Она заново создаст нужные ей системные объекты, не учитывая новые поля STT.

Пример кода для удаления таблиц (использовать с осторожностью):

-- ВНИМАНИЕ: Только для ознакомления после создания бэкапа!
DROP TABLE _STTModelsDesc;
DROP TABLE _STTModelsDescs;
GO

Рекомендации по предотвращению проблемы

Чтобы в будущем не сталкиваться с подобными ситуациями, проанализируем правила работы с разными версиями платформы:

• Правило одного релиза: Старайтесь не открывать одну и ту же базу разными версиями платформы (особенно если разница между ними составляет более 10–15 релизов). Платформа 1С всегда стремится обновить структуру таблиц до актуальной.
• Бэкап перед обновлением: Всегда делайте выгрузку .dt или копию файла .1CD перед первым запуском базы в новой версии 1С.
• Использование учебных версий: Помните, что учебные версии имеют свои ограничения в механизмах конвертации, и ошибки SDBL в них могут проявляться чаще из-за невозможности полноценного использования инструментов СУБД.
• Конвертация через XML: Если база окончательно «сломалась» для старой платформы, но открывается в новой, используйте универсальную обработку «Выгрузка загрузка данных XML». Создайте пустую базу на старой платформе и перенесите данные в неё — это гарантирует чистую схему DBSchema без лишних полей Language.

Подводя итог, отметим, что ошибка SDBL с таблицами STTModelsDesc — это следствие эволюции платформы. Использование штатного механизма Реструктуризации в версии 8.3.23+ является самым надежным способом «подружить» структуру базы со старыми движками 1С.