Ошибка «Ошибка SDBL: Ожидается выражение (pos=...)» — это одна из самых неприятных проблем, с которой может столкнуться администратор или разработчик 1С. Она сигнализирует о глубоком конфликте между прикладным уровнем платформы и уровнем системы управления базами данных (СУБД). SDBL (Simple Data Base Language) — это внутренний язык запросов 1С, который платформа использует для трансляции своих команд в понятный для SQL-сервера язык. Если транслятор встречает некорректное описание метаданных, он не может построить SQL-запрос и выдает ошибку с указанием позиции (pos) в строке, где произошел сбой.
Чаще всего эта ситуация возникает после так называемого «динамического обновления» («демонического», как его называют в узких кругах), когда изменения в конфигурацию вносятся при работающих пользователях. Рассмотрим подробные алгоритмы решения этой проблемы, начиная от самых простых и заканчивая радикальными методами восстановления структуры базы данных.
Как показывает практика и многочисленные подтверждения участников обсуждения, в 80% случаев проблема кроется в локальном кэше конфигурации на компьютере пользователя или на сервере приложений 1С. Система пытается использовать старое описание структуры данных, в то время как база уже ожидает новую структуру.
Проанализируем процесс очистки по шагам:
%AppData%\1C\1cv8\ и %LocalAppData%\1C\1cv8\. Удалим все папки с именами в виде длинных идентификаторов.snaccfg в каталоге сервера приложений (обычно это C:\Program Files\1cv8\srvinfo\reg_1541\).После очистки кэша транслятор SDBL будет вынужден заново считать описание метаданных из таблицы Config, что часто устраняет ошибку «Ожидается выражение».
Если очистка кэша не помогла, значит, проблема зафиксирована в самой базе данных (в таблице DBSchema или Config). Рассмотрим интересный и эффективный метод, предложенный одним из участников, столкнувшимся с этой ошибкой при обновлении платформы.
Разберем алгоритм совместных действий:
Конфигурация -> Сохранить конфигурацию в файл...). Получим файл *.cf.Конфигурация -> Поддержка -> Настройка поддержки -> Снять с поддержки). Это разорвет связи с некорректными объектами поставщика, которые могут вызывать ошибку SDBL.Конфигурация -> Сравнить, объединить с конфигурацией из файла, выбрав наш ранее сохраненный *.cf. При вопросе о постановке на поддержку отвечаем утвердительно.Этот метод позволяет «пересобрать» внутренние таблицы схем, исключив из них мусорные записи, оставшиеся после неудачного динамического обновления.
Иногда ошибка возникает из-за того, что в базе «зависает» запись о незавершенном обновлении. В 1С есть несколько ключевых таблиц, отвечающих за это. Рассмотрим, как проанализировать их состояние через SQL Management Studio.
Внимание! Перед любыми действиями с SQL-таблицами обязательно создайте полную резервную копию базы данных.
Проанализируем таблицу Config. В ней хранятся три варианта конфигурации: основная, расширения и конфигурация базы данных. Ошибка часто возникает из-за расхождения между ними. Попробуем очистить таблицу временных обновлений, которая часто вызывает сбои в SDBL-процессоре:
-- Проверка наличия временных данных обновления
SELECT * FROM dbo.ConfigSave;
-- Очистка таблицы, если в ней зависли данные после неудачного динамического обновления
DELETE FROM dbo.ConfigSave;
Также стоит обратить внимание на таблицу DBSchema. Она содержит бинарное описание всей структуры таблиц. Если она повреждена, 1С не знает, как строить запросы. В некоторых случаях помогает очистка таблицы DBSchema (в пустой или тестовой копии!), после чего при запуске конфигуратора 1С попытается восстановить ее из данных таблицы Config.
Выясним причину, упомянутую в первом сообщении темы: «Задано одинаковое имя для измерения и ресурса». SDBL крайне чувствителен к уникальности имен в рамках одной таблицы. Если в результате сбоя метаданных у вас появился «невидимый» ресурс, который конфликтует с существующим измерением, это гарантированно приведет к ошибке Expected expression.
Рассмотрим порядок действий для диагностики:
Посмотрим на ситуацию, когда ошибка pos=... возникает не сразу, а при открытии конкретных списков. Это может быть связано с механизмом RLS (Restriction at Row Level). SDBL-транслятор добавляет условия ограничения прав в итоговый SQL-запрос. Если в тексте шаблона RLS есть синтаксическая ошибка или он обращается к реквизиту, который «исчез» из DBSchema, возникнет ошибка.
Рекомендация: Попробуйте зайти в базу под пользователем с полными правами. Если ошибка исчезла — проблема в настройках ролей и шаблонах ограничений. Проанализируйте текст запроса в ролях на наличие некорректных выражений.
Также проанализируем влияние полнотекстового поиска. Иногда индекс поиска пытается обратиться к данным, структура которых изменилась. Попробуйте выполнить следующие действия:
Управление полнотекстовым поиском.Подводя итог, можно сказать, что ошибка SDBL — это всегда следствие рассинхронизации. Для предотвращения таких ситуаций настоятельно рекомендуем отказаться от динамического обновления в крупных базах или базах с критически важными данными. Всегда делайте выгрузку .dt или бэкап SQL перед обновлением конфигурации.
Если же беда случилась, начните с самого простого — очистки кэша на всех уровнях. Если это не помогло, переходите к манипуляциям с файлом .cf и снятием конфигурации с поддержки, чтобы «вылечить» структуру метаданных внутри самой базы.