Как удалить пустую запись в табличной части справочника при ошибке SDBL?

← На главную

При обслуживании и тестировании баз данных на платформе 1С:Предприятие разработчики и администраторы иногда сталкиваются со специфическими ошибками логической целостности. Одна из самых коварных проблем — появление «осиротевших» строк в табличных частях. Физически запись существует в таблице базы данных, но ее поле связи с родителем (владельцем) содержит пустой уникальный идентификатор (GUID). При попытке выполнить стандартное Тестирование и исправление (ТИИ) система аварийно завершает работу с сообщением: «Ошибка SDBL: Тип поля FLD... несовместим с типом литерала UNDEFINED».

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

Почему возникает ошибка SDBL и не работают стандартные утилиты?

Давайте проанализируем внутреннее устройство СУБД 1С. Любая табличная часть справочника или документа в физической таблице базы данных хранится отдельно от основной таблицы объекта. Связь между ними осуществляется с помощью специального служебного поля ссылки (обычно это поле называется по шаблону _ReferenceXX_IDRRef для справочников или _DocumentXX_IDRRef для документов).

Если в результате аппаратного сбоя, некорректного динамического обновления или программной ошибки в таблицу ТЧ записывается строка, у которой поле связи заполнено двоичными нулями (00000000-0000-0000-0000-000000000000), возникает логическое противоречие. Запись в подчиненной таблице есть, а объекта-владельца с таким идентификатором не существует.

Рассмотрим, почему штатные механизмы диагностики не могут исправить эту ситуацию:

Утилита chdbfl.exe не находит ошибок. Программа chdbfl.exe предназначена исключительно для проверки физической целостности файла базы данных 1Cv8.1cd (структура страниц, целостность заголовков таблиц, индексы). Она не проверяет логические связи между таблицами и не знает, что запись ТЧ должна обязательно ссылаться на существующий элемент справочника.
Тестирование и исправление завершается аварийно. При выборе режима «Проверка логической целостности» платформа пытается сопоставить каждую строку ТЧ со справочником-владельцем. Натыкаясь на нулевой GUID, внутренний транслятор запросов платформы (SDBL) пытается интерпретировать пустую ссылку как значение Неопределено (UNDEFINED). Из-за строгого соответствия типов СУБД отвергает это сравнение, и ТИИ «вылетает» с ошибкой несовместимости типов, так и не успев удалить дефектную строку.
Программный метод через код 1С не работает. В платформе 1С невозможно получить объект по пустой ссылке для его редактирования. Код Справочники.Организации.ПустаяСсылка().ПолучитьОбъект() всегда возвращает Неопределено, следовательно, мы не можем очистить или перезаписать табличную часть пустой ссылки штатными методами встроенного языка.

Ниже мы подробно разберем три рабочих сценария решения этой проблемы.

Решение А. Прямое удаление записи в СУБД (для клиент-серверных баз)

Если ваша информационная база работает в клиент-серверном режиме (под управлением MS SQL Server, PostgreSQL, IBM DB2 или Oracle), исправить проблему проще всего. Нам достаточно выполнить прямой запрос на удаление проблемной строки из соответствующей физической таблицы.

Рассмотрим этот процесс по шагам:

Шаг 1. Определение физического имени таблицы и полей. Сначала нам необходимо выяснить, в какой именно таблице СУБД хранятся данные нашей табличной части. Для этого мы можем запустить обработку «Получить структуру хранения базы данных» или выполнить простой программный код во внешней обработке:


СтруктураБазы = ПолучитьСтруктуруХраненияБазыДанных("Справочник.Организации", Истина);
Для Каждого Таблица Из СтруктураБазы Цикл
    Если Таблица.ИмяМетаданных = "Справочник.Организации.ТабличнаяЧасть.КонтактнаяИнформация" Тогда
        Сообщить("Имя таблицы в СУБД: " + Таблица.ИмяТаблицыХранения);
        Для Каждого Поле Из Таблица.Поля Цикл
            Если Поле.ИмяМетаданных = "Ссылка" Тогда
                Сообщить("Имя поля связи: " + Поле.ИмяПоляХранения);
            КонецЕсли;
        КонецЦикла;
    КонецЕсли;
КонецЦикла;

Предположим, что в результате мы выяснили: физическая таблица называется _Reference31_VT3892, а поле связи (идентификатор владельца) — _Reference31_IDRRef.

Шаг 2. Выполнение SQL-запроса на удаление. Теперь нам нужно открыть консоль управления СУБД (например, SQL Server Management Studio или pgAdmin) и выполнить запрос на удаление записи, у которой поле связи состоит из одних нулей.

Для базы данных под управлением MS SQL Server запрос будет выглядеть следующим образом:


DELETE FROM _Reference31_VT3892 
WHERE _Reference31_IDRRef = 0x00000000000000000000000000000000;

Для базы данных под управлением PostgreSQL синтаксис двоичного литерала будет немного отличаться:


DELETE FROM _Reference31_VT3892 
WHERE _Reference31_IDRRef = '\x00000000000000000000000000000000';

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

Решение Б. Пересоздание табличной части через XML (для файловых баз)

Что делать, если база данных файловая, разворачивать SQL-сервер нет возможности, а использовать сторонние низкоуровневые утилиты не хочется? Мы можем прибегнуть к стандартному методу выгрузки/загрузки данных с временным удалением метаданных.

Проанализируем по шагам этот алгоритм:

Выгружаем корректные данные. Запустим базу в режиме «1С:Предприятие» и воспользуемся типовой обработкой «Универсальный обмен данными в формате XML». Нам нужно выгрузить только наш справочник Организации. Поскольку выгрузка работает через объектную модель 1С, она будет обходить только существующие элементы справочника. Наша «осиротевшая» строка из табличной части не имеет родителя, поэтому она гарантированно не попадет в файл выгрузки XML.
Делаем резервную копию конфигурации. Откроем Конфигуратор и сохраним конфигурацию в файл (Конфигурация -> Сохранить конфигурацию в файл...).
Удаляем табличную часть. В дереве метаданных найдем справочник Организации, перейдем на вкладку «Табличные части», выберем поврежденную табличную часть (например, КонтактнаяИнформация) и удалим её.
Обновляем конфигурацию базы данных (клавиша F7). При этом действии платформа физически удалит из файла 1Cv8.1cd таблицу, предназначенную для хранения этой табличной части, вместе со всеми записями (включая дефектную пустую строку).
Восстанавливаем структуру метаданных. Теперь нам нужно вернуть табличную часть на место. Для этого выполним сравнение и объединение с ранее сохраненным файлом конфигурации (или просто вручную добавим табличную часть обратно с точно такими же именами и типами реквизитов). Снова нажмем F7 для создания новой, абсолютно чистой таблицы в базе данных.
Загружаем данные. Запустим информационную базу в режиме «Предприятие» и через ту же обработку «Универсальный обмен данными в формате XML» загрузим данные обратно. В результате все организации восстановят свои корректные данные табличных частей, а поврежденная пустая строка навсегда исчезнет.

Решение В. Использование специализированных утилит (Tool1CD)

Еще один эффективный метод для файловых баз — прямое редактирование таблиц базы данных с помощью сторонней утилиты Tool1CD (или ее аналогов для работы с форматом 1CD). Этот инструмент позволяет просматривать и редактировать таблицы файловой базы напрямую, минуя уровень платформы 1С.

Выполним следующие действия:

Обязательно закроем базу 1С и скопируем файл 1Cv8.1cd в отдельный каталог для создания резервной копии. Ни в коем случае не выполняйте операции редактирования на работающей базе!
Запустим утилиту Tool1CD и откроем в ней файл базы данных.
В списке таблиц найдем физическую таблицу, соответствующую нашей табличной части (например, _REFERENCE31_VT3892).
Перейдем к просмотру содержимого этой таблицы. Отсортируем записи по полю связи с родителем (идентификатором владельца).
Найдем строку, в которой поле идентификатора полностью заполнено нулями (это визуально заметно на фоне остальных заполненных GUID-ов).
Используя встроенный инструментарий редактирования утилиты, удалим дефектную строку и сохраним изменения в файле базы данных.

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

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

Мы подробно рассмотрели технические нюансы возникновения ошибки SDBL, связанной с «осиротевшими» записями табличных частей, и разобрали три метода борьбы с этой неполадкой. На практике наиболее быстрым и безопасным решением является перевод базы на SQL и удаление записи простым запросом DELETE. Для небольших файловых баз отлично подойдет метод с временным удалением табличной части через XML-выгрузку, так как он гарантирует полную сохранность структуры базы данных силами самой платформы.