Как исправить ошибку SDBL с кодом типа 21 и отсутствующим полем Fld после обновления 1С:ERP?

← На главную

При обновлении тяжелых конфигураций, таких как 1С:ERP или Комплексная автоматизация, администраторы часто сталкиваются с критическими сбоями механизма SDBL (Simple Data Barrier Language). Одной из самых неприятных является ошибка вида: «Ошибка SDBL: Несоответствие типа 21:0000000000000000000 и Fld622287». Ситуация осложняется тем, что указанное поле может отсутствовать как в структуре хранения базы данных, так и в физических таблицах SQL-сервера. Рассмотрим детально, почему это происходит и как исправить ситуацию, когда стандартное Тестирование и Исправление (ТиИ) или выгрузка в .dt не помогают.

Разберем природу ошибки и значение кода 21

Для начала проанализируем само сообщение. Код 21 в терминологии внутреннего языка запросов платформы 1С часто соответствует системному типу данных, связанному с пустыми ссылками или специфическими объектами метаданных (например, ссылками на документы или определенные регистры). Значение 21:0000000000000000000 прямо указывает на то, что система пытается обработать «пустую ссылку» неопределенного типа в поле, которое она ожидает увидеть в структуре, но не находит.

Отсутствие поля Fld622287 при поиске через INFORMATION_SCHEMA.COLUMNS в SQL означает, что расхождение возникло на уровне логической схемы 1С. Платформа «думает», что поле должно быть, и пытается обратиться к нему в запросе, но база данных об этом поле ничего не знает. Это типичный признак повреждения кэша метаданных в таблицах Config, Params или проблем с «хвостами» динамических обновлений.

Шаг 1. Диагностика через Технологический журнал

Если ошибка возникает на этапе выполнения обработчиков обновления (часто на отметке 25% при первом запуске), нам необходимо точно выяснить, какой SQL-запрос вызывает сбой. Для этого настроим Технологический журнал. Проанализируем событие SDBL и EXCP. Рассмотрим пример настройки logcfg.xml:


<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\LOGS\SDBL" history="24">
    <event>
      <eq property="Name" value="SDBL"/>
    </event>
    <event>
      <eq property="Name" value="EXCP"/>
    </event>
    <property name="all"/>
  </log>
</config>

После повторного возникновения ошибки изучим логи. В тексте события SDBL перед самым исключением будет виден текст запроса. Это позволит нам понять, к какой именно таблице (например, _InfoRg21 или временной таблице #tt...) относится злополучное поле Fld622287. Часто оказывается, что это поле принадлежит временной таблице, создаваемой платформой в процессе реструктуризации данных, которая удаляется сразу после отката транзакции.

Шаг 2. Работа с системной таблицей dbnames

Проанализируем ситуацию с таблицей соответствия имен. В 1С данные о соответствии объектов метаданных и полей SQL хранятся в специальном бинарном ресурсе dbnames в таблице Params или Config. Если в этом ресурсе прописано поле, которого нет в физической таблице, возникнет ошибка SDBL.

Рассмотрим вариант решения через принудительное обновление схемы:

Сделаем полную резервную копию базы данных SQL.
Попробуем выполнить полную загрузку конфигурации из файла .cf (команда «Загрузить конфигурацию из файла», а не «Сравнить/Объединить»). Это должно полностью перезаписать таблицы Config.
Если это не помогло, можно прибегнуть к радикальному методу (только на копии!): удалению записи DBSchema из таблицы Params. Это заставит платформу выполнить полную реструктуризацию при следующем входе в конфигуратор.

DELETE FROM dbo._Params WHERE _FileName = 'DBSchema'

Шаг 3. Влияние расширений и патчей

Выясним причину возможного конфликта со стороны расширений. В современных версиях ERP часто автоматически устанавливаются патчи (исправления от 1С), которые по сути являются расширениями. Если патч добавил реквизит в документ или регистр, а основное обновление конфигурации пытается изменить тот же объект, возникает конфликт имен Fld....

Проанализируем следующие действия:

Полностью отключим все расширения перед обновлением.
Проверим наличие патчей в списке расширений и удалим их.
Очистим таблицу _ConfigAndSharedSettings, где могут храниться настройки расширений, мешающие корректной реструктуризации.

Шаг 4. Очистка кэша серверных вызовов и динамических обновлений

Одной из причин появления «призрачных» полей являются следы динамических обновлений. Рассмотрим, как очистить базу от этих хвостов на уровне СУБД. Нам нужно убедиться, что таблицы Config и ConfigSave идентичны и не содержат записей о незавершенных сеансах обновления.

Посмотрим на пример очистки системных таблиц (выполнять крайне осторожно):


-- Удаление записей о динамических обновлениях
DELETE FROM Config WHERE [FileName] = 'commit'
DELETE FROM Config WHERE [FileName] = 'dbnames.new'

После выполнения данных операций обязательно очистим серверный кэш 1С (папку snccntx в каталоге пользователя, под которым запущен сервер 1С).

Шаг 5. Проверка целостности данных в SQL

Если ошибка 21:0000000000000000000 указывает на конкретную таблицу регистра (например, _InfoRg21), проверим её содержимое на наличие некорректных типов данных. Бывают случаи, когда в поле, имеющем составной тип, записывается ссылка на объект, который был удален или метаданные которого изменились в новой версии конфигурации.

Рассмотрим SQL-запрос для поиска «битых» ссылок в подозрительной таблице:


SELECT * FROM _InfoRg21 
WHERE _FldXXX_TYPE = 0x15 -- Код типа 21 в HEX
AND _FldXXX_RTRef = 0x00000000

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

Резюме и рекомендации

Подводя итог, можно сказать, что ошибка SDBL с неопределенным полем Fld в 1С:ERP — это всегда следствие рассинхронизации логического и физического уровней базы данных. Проанализируем основные рекомендации:

Всегда обновляйте платформу 1С до последней актуальной версии перед обновлением ERP (в новых релизах платформы механизмы SDBL работают стабильнее).
Избегайте динамических обновлений ("демонских") в крупных базах.
Перед обновлением делайте shrink лога транзакций и очистку процедурного кэша SQL: DBCC FREEPROCCACHE.
Если поле не находится в SQL — ищите его в Технологическом журнале, чтобы понять, какой объект метаданных (Регистр, Документ) его порождает.

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