Как исправить ошибку SDBL: Ссылка на таблицу DocumentXX недопустима при обновлении базы данных 1С?

При активной разработке, обновлении или переходе на типовые конфигурации разработчики 1С часто сталкиваются с крайне неприятной проблемой — падением платформы при попытке обновить конфигурацию базы данных. Ошибка выглядит следующим образом: «Ошибка SDBL: Ссылка на таблицу Document87 (или Reference87) недопустима. Нет таблицы или отсутствует RefSelf». При этом физически таблица может присутствовать в базе данных SQL, ссылки на удаляемый объект в конфигурации вычищены, а стандартная утилита chdbfl.exe и тестирование и исправление (ТиИ) не находят видимых повреждений файла базы данных или СУБД.

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

Почему возникает ошибка SDBL и отсутствует RefSelf?

Служба SDBL (Simple Database Layer) — это внутренний уровень абстракции платформы «1С:Предприятие», который транслирует логические запросы платформы в физические SQL-команды для конкретной СУБД (MS SQL, PostgreSQL, IBM DB2) или в структуру файловой базы данных. Ошибка с упоминанием отсутствия RefSelf возникает в тот момент, когда в СУБД или во внутренней таблице метаданных SchemaStorage нарушается связь между логическим описанием объекта в конфигурации и его физическим представлением в базе данных.

Платформа пытается сопоставить уникальный идентификатор (UUID) удаляемого или изменяемого объекта (например, документа Document87) с метаданными СУБД. Если физическая таблица была удалена некорректно или метаданные СУБД рассинхронизировались во время незавершенного обновления, SDBL считает, что таблица повреждена или у нее отсутствует колонка первичного ключа (ссылка на саму себя — RefSelf, соответствующая полю _IDRRef).

---

Способ 1. Обходной путь через создание распределенной информационной базы (РИБ)

Этот метод является одним из самых надежных, так как он выполняется полностью штатными средствами платформы 1С и не требует прямого редактирования таблиц SQL. Мы воспользуемся механизмом создания начального образа РИБ, в ходе которого платформа заново генерирует чистую структуру таблиц базы данных, избавляясь от мусорных связей и ошибок SDBL.

Рассмотрим по шагам данный алгоритм работы:

1. Откройте исходную информационную базу в режиме «1С:Предприятие».
2. Перейдите в список планов обмена (например, откройте полный план обмена или создайте временный технический план обмена, в состав которого входит вся конфигурация).
3. Создайте новый подчиненный узел плана обмена.
4. Выделите созданный узел и выполните команду «Создать начальный образ». Выберите вариант сохранения в файловую базу или создайте новую пустую базу на сервере СУБД. Платформа полностью сформирует новую чистую базу данных на основе текущей рабочей схемы.
5. Запустите полученную базу (начальный образ) в режиме Конфигуратора. Вы увидите, что в ней включена возможность изменения, но она связана с главным узлом.
6. Теперь нам необходимо отключить эту базу от главного узла, чтобы она стала полностью автономной. Для этого запустите базу в режиме «Предприятие», откройте внешнюю обработку или создайте обработку во встроенном языке и выполните следующий код:

Процедура ОтключитьБазуОтРИБ()
    ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
КонецПроцедуры

1. После выполнения этого кода закройте сеанс «Предприятия» и снова зайдите в Конфигуратор этой базы. Теперь она больше не является подчиненным узлом.
2. Спокойно удалите проблемный справочник или документ из дерева метаданных и запустите обновление конфигурации базы данных (клавиша F7). Обновление должно пройти гладко и без ошибок SDBL.
3. Выгрузите полученную рабочую конфигурацию и данные обратно в основную рабочую базу (или просто начните использовать созданную базу как новую рабочую).

---

Способ 2. Точечное тестирование и исправление с реструктуризацией таблиц

Многие разработчики совершают ошибку, запуская стандартное «Тестирование и исправление» (ТиИ) со всеми включенными флагами. В этом случае процесс прерывается на фазе проверки логической целостности, выдавая все ту же ошибку SDBL. Нам нужно применить изолированную реструктуризацию.

Проанализируем этот процесс:

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

---

Способ 3. Очистка таблиц регистрации изменений в SQL

Если ваша база данных работает на SQL Server или PostgreSQL, ошибка SDBL часто бывает вызвана зависшими ссылками на удаляемый объект в таблицах регистрации изменений планов обмена. Платформа пытается удалить таблицу объекта, но триггеры СУБД или связанные записи в системных таблицах изменений блокируют эту операцию.

Выясним причину и исправим её на уровне СУБД:

1. Откройте СУБД через SQL Server Management Studio (или pgAdmin для PostgreSQL).
2. Выполните следующий SQL-запрос для очистки служебных таблиц регистрации изменений конфигурации (вместо dbo укажите вашу схему базы данных, если она отличается):

-- Очистка таблиц регистрации изменений конфигурации
TRUNCATE TABLE dbo._ConfigChngR;
TRUNCATE TABLE dbo._ConfigChngR_ExtProps;

После успешного выполнения этих запросов вернитесь в Конфигуратор 1С и повторите попытку удаления объекта и обновления конфигурации базы данных.

---

Способ 4. Ручная синхронизация UUID метаданных через выгрузку в XML

Иногда платформа 1С теряет связь между основной конфигурацией и конфигурацией базы данных из-за расхождения их внутренних идентификаторов (UUID). Мы можем восстановить эту связь вручную, перенеся UUID из конфигурации базы данных в основную конфигурацию.

Разберем этот метод по шагам:

1. Выгрузите основную конфигурацию в файлы XML через меню: Конфигурация — Разработка — Выгрузить конфигурацию в файлы. Назовем эту директорию Папка_1.
2. В Конфигураторе откатите изменения к конфигурации базы данных (меню Конфигурация — Конфигурация базы данных — Вернуться к конфигурации БД).
3. Выгрузите теперь конфигурацию базы данных в XML-файлы в другую папку (Папка_2).
4. Откройте файл ConfigDumpInfo.xml из Папки_2 и найдите в нем описание проблемного объекта (например, вашего удаляемого документа). Скопируйте значение его атрибута id (это и есть правильный UUID метаданных базы данных).
5. Откройте аналогичный файл в Папке_1 и замените UUID проблемного объекта на скопированное значение. Также замените UUID в самом XML-файле описания объекта метаданных (первая строка тега).
6. Загрузите измененные файлы обратно в Конфигуратор из Папки_1 и примените обновление конфигурации. Теперь платформа сможет сопоставить таблицы и успешно завершит удаление.

---

Способ 5. Создание «заглушки» таблицы на уровне SQL

Если платформа упорно жалуется на отсутствие физической таблицы Document87 (или Reference87 для справочников) и не может из-за этого завершить обновление метаданных, мы можем обмануть SDBL, принудительно создав пустую таблицу-заглушку с требуемым именем и ключевым полем _IDRRef прямо в СУБД.

Рассмотрим пример SQL-скрипта для MS SQL Server:

-- Создание пустой таблицы-заглушки с обязательным полем ссылки RefSelf
CREATE TABLE dbo._Document87 (
    _IDRRef BINARY(16) NOT NULL,
    _Version ROWVERSION NOT NULL,
    _Marked BINARY(1) NOT NULL,
    _Date_Time DATETIME NOT NULL,
    _Number NVARCHAR(10) NOT NULL,
    CONSTRAINT PK__Document87 PRIMARY KEY CLUSTERED (_IDRRef)
);

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

---

Способ 6. Поиск скрытых ссылок в составных типах данных

Часто удаляемый объект уже отсутствует на форме и в реквизитах, но ссылка на него осталась в скрытых метаданных платформы:

• В определяемых типах (ОпределяемыйТип);
• В составе типов Плана видов характеристик;
• В критериях отбора или составах планов обмена.

Чтобы выявить эти скрытые зависимости, запустите проверку конфигурации (меню Конфигурация — Проверить конфигурацию), обязательно установив флаг «Поиск некорректных ссылок в метаданных» (остальные флаги для скорости можно временно отключить). Если проверка обнаружит битые ссылки, откройте указанные объекты, исключите из состава типов удаляемый документ или справочник, сохраните изменения и повторите обновление базы данных.

Резюме

Мы проанализировали причины возникновения ошибки SDBL и детально разобрали шесть способов ее решения. Для файловых баз наиболее простым и безопасным методом является создание РИБ-образа (Способ 1), а для клиент-серверных вариантов баз данных высокую эффективность показывают SQL-скрипты очистки кэша изменений и создание таблиц-заглушек (Способы 3 и 5).