Как исправить ошибку SDBL "ожидается имя таблицы (pos=6)" при изменении режима совместимости в 1С?

← На главную

При переходе на новые версии платформы 1С:Предприятие часто возникает необходимость повышения режима совместимости конфигурации. Одной из самых коварных проблем в этом процессе является ошибка "ошибка sdbl ожидается имя таблицы (pos=6)". Особенно остро она проявляется в конфигурациях на обычных формах (например, УТ 10.3) при использовании механизмов распределенных информационных баз (РИБ). Рассмотрим подробно причины возникновения этой ошибки и разберем пошаговые методики ее устранения.

Разберем природу ошибки SDBL

Для начала проанализируем ситуацию с технической стороны. SDBL (Simple Data Base Language) — это внутренний язык платформы 1С, который служит прослойкой между кодом на языке 1С и SQL-запросами к конкретной СУБД (MS SQL Server, PostgreSQL и др.). Когда мы меняем режим совместимости (например, с 8.2.13 на 8.2.16 или выше), платформа меняет алгоритмы трансляции этих запросов.

Ошибка в позиции pos=6 сигнализирует о том, что парсер SDBL ожидает имя физической таблицы в базе данных, но не находит его. Это происходит из-за рассинхронизации между метаданными конфигурации и схемой базы данных (таблица DBSchema). В частности, это часто касается системных таблиц регистрации изменений (_ChangeRec), которые используются в планах обмена.

Решение 1: Использование платформы 8.2.19 как промежуточного этапа

Как показывает практика и опыт многих разработчиков, прямой переход между значительно различающимися режимами совместимости на платформе 8.3 иногда проходит некорректно. Рассмотрим наиболее эффективный алгоритм решения проблемы:

Подготовим окружение: Установим последнюю стабильную версию платформы ветки 8.2, а именно 8.2.19.130. Эта версия содержит наиболее совершенные механизмы реструктуризации для старого формата баз.
Запустим базу под 8.2.19: Откроем информационную базу в конфигураторе именно под этой версией платформы.
Изменим режим совместимости: Установим требуемый режим (например, 8.2.16) или вовсе отключим совместимость, если планируется полный переход на 8.3.
Выполним реструктуризацию: Это критически важный шаг. Перейдем в меню "Администрирование" — "Тестирование и исправление". Выберем только пункт "Реструктуризация таблиц информационной базы".
Завершим переход: После успешного выполнения реструктуризации сохраним конфигурацию. Теперь базу можно открывать под платформой 8.3.x — ошибка SDBL должна исчезнуть.

Решение 2: Манипуляции с планами обмена и регистрацией изменений

Если ошибка возникает именно при попытке синхронизации в распределенной базе, проанализируем состояние таблиц регистрации изменений. При смене режима совместимости структура индексов в этих таблицах может измениться, и старые записи становятся "невидимыми" или "битыми" для нового парсера SDBL.

Выясним причину через очистку регистрации. Попробуем выполнить следующий код для проблемного узла (предварительно сделав бэкап!):


// Очистка регистрации для всех объектов плана обмена
ПланыОбмена.УдалитьРегистрациюИзменений(СсылкаНаУзел);

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


// Пример повторной регистрации справочника Номенклатура
Выборка = Справочники.Номенклатура.Выбрать();
Пока Выборка.Следующий() Цикл
    ПланыОбмена.ЗарегистрироватьИзменения(СсылкаНаУзел, Выборка.Ссылка);
КонецЦикла;

Решение 3: Восстановление поврежденного узла РИБ

Иногда после сбоя при обновлении конфигурации в периферийной базе данных (РБ) стандартные методы ТИИ и chdbfl.exe не помогают. В этом случае рассмотрим методику пересоздания образа:

В центральной базе создадим новый узел плана обмена (клон проблемного узла).
Сформируем начальный образ для этого узла.
Если в "сломанной" базе остались ценные данные, которые не успели уйти в центр, воспользуемся обработкой "Выгрузка и загрузка данных XML". Перенесем документы и справочники из старой периферийной базы в новый образ.
Заменим старую базу новым образом и восстановим обмен.

Особенности для серверных баз (MS SQL / PostgreSQL)

Если ваша база работает в клиент-серверном варианте, проблема может быть связана с серверным кэшем метаданных. Выполним следующие шаги для очистки:

Остановим службу 1C:Enterprise Server.
Перейдем в каталог srvinfo (обычно в C:\Program Files\1cv8\srvinfo).
Найдем папку с идентификатором (GUID) вашей базы и удалим в ней все папки, кроме файлов данных самой СУБД (если они вдруг там). В частности, нас интересуют папки reg_1541 и подпапки с кэшем сеансов.
Запустим службу сервера.

Также проанализируем возможность использования разных версий серверов одновременно. Если база большая (например, более 150 Гб), и мы боимся делать dt-выгрузку, можно установить сервер 8.2 и 8.3 на одну машину, разнеся их по портам (например, 1540 и 1640). Это позволит подключаться к одной и той же SQL-базе разными версиями платформы для выполнения регламентных операций по переходу.

Важные замечания по реструктуризации

Посмотрим на ситуацию с ТИИ. Обычное "Тестирование и исправление" может не дать результата, если не выбрана опция реструктуризации. Реструктуризация — это процесс создания новых физических таблиц в БД, переноса туда данных из старых таблиц и удаления старых. Именно этот процесс "пересобирает" базу под требования текущего режима совместимости, исправляя ошибки формата SDBL.

Если база файловая, обязательно перед всеми действиями проверим ее утилитой chdbfl.exe. Хотя она и не лечит логические ошибки SDBL, она устраняет физические повреждения блоков файла .1CD, которые могут блокировать процесс реструктуризации.

Подведем итог: Ошибка pos=6 при смене режима совместимости — это почти всегда следствие "кривой" трансформации таблиц метаданных. Ключ к решению — использование промежуточной версии 8.2.19, полная реструктуризация таблиц и, при необходимости, пересоздание таблиц регистрации изменений в планах обмена.