При активной разработке в среде 1С:Предприятие 8.3 программисты часто сталкиваются с ситуацией, когда созданный ранее объект метаданных (справочник, документ или перечисление) становится ненужным. Казалось бы, процедура проста: удалить объект из дерева конфигурации и обновить конфигурацию базы данных (F7). Однако в ряде случаев этот процесс прерывается критической ошибкой SDBL: Ссылка на таблицу ReferenceX недопустима. Нет таблицы или отсутствует RefSelf.
В этой статье мы подробно разберем, почему возникает эта ошибка, как восстановить работоспособность базы данных и что делать, если после исправления основной ошибки начали появляться проблемы с отображением реквизитов на формах.
Для начала проанализируем, что скрывается за аббревиатурой SDBL (Simple Data Bank Language). Это внутренний язык запросов платформы 1С, который служит прослойкой между логикой метаданных и физическими таблицами СУБД (MS SQL Server, PostgreSQL или файловая база 1CD). Ошибка RefSelf сигнализирует о том, что механизм обновления конфигурации обнаружил рассинхронизацию.
Поле RefSelf — это системный идентификатор ссылки объекта на самого себя, который должен присутствовать в любой таблице ссылочного типа. Если в процессе трансформации структуры базы данных 1С пытается обратиться к таблице удаляемого справочника, но не находит в ней обязательных системных полей или саму таблицу в системном описании DBSchema, транзакция откатывается. Это часто происходит из-за накопившихся ошибок в кэше или незавершенных предыдущих реструктуризаций (например, при использовании "динамического обновления").
Как показывает практика, наиболее эффективным и быстрым способом решения данной проблемы является запуск штатного механизма проверки целостности базы данных. Разберем по шагам, как правильно выполнить эту процедуру:
.dt или копирование файла .1CD). Любые манипуляции со структурой таблиц могут привести к необратимой потере данных при сбое питания или платформы.Важное замечание: Реструктуризация заново пересоздает физические таблицы в СУБД на основе текущего описания метаданных. Это позволяет "вычистить" упоминания об удаленном справочнике Reference24 из системных таблиц, которые блокировали обновление.
Если стандартная реструктуризация не помогает, рассмотрим более сложный, но действенный метод, основанный на создании "чистого" образа базы. Этот метод помогает, когда ошибка засела глубоко в конфигурации базы данных:
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
Иногда ошибка SDBL является ложной и вызвана тем, что платформа пытается использовать старое описание структуры таблиц из локального кэша. Проанализируем ситуацию: если на одном компьютере ошибка воспроизводится, а на другом (с той же базой) — нет, значит, проблема в кэше.
Для исправления выполним следующие действия:
%AppData%\1C\1cv8\
%LocalAppData%\1C\1cv8\
Рассмотрим ситуацию, когда после успешного удаления справочника и обновления конфигурации в режиме "Предприятие" начинает возникать новая ошибка при открытии форм документов: Table and field Description not contained in FROM.
Эта ошибка означает, что в конфигурации остались "битые ссылки" на удаленный объект. Выясним, где они могут прятаться:
Description not contained in FROM часто возникает, когда запрос пытается получить поле Наименование (Description) у объекта, тип которого больше не определен.Произвольного запроса в динамических списках на формах. Если там фигурировало соединение с удаленной таблицей, его нужно вычистить вручную.Проанализируем пример кода, который может вызывать подобное поведение после удаления справочника НовыйСправочник:
// Ошибка возникнет здесь, если тип реквизита "Спецификация"
// ранее был "СправочникСсылка.НовыйСправочник"
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Продажи.Номенклатура,
| Продажи.Спецификация.Наименование КАК ОписаниеСпец
|ИЗ
| РегистрНакопления.Продажи КАК Продажи";
В данном случае, после удаления справочника, обращение через точку Продажи.Спецификация.Наименование станет невалидным, так как поле Description (Наименование) больше не существует в контексте этого реквизита.
Подводя итог, можно сказать, что ошибка SDBL при удалении объектов — это чаще всего следствие технического сбоя в структуре DBSchema. Основным инструментом лечения остается реструктуризация. Чтобы минимизировать риск возникновения таких проблем в будущем, старайтесь избегать "динамических обновлений" (обновлений "на лету") при изменении структуры метаданных и всегда делайте контрольное тестирование базы после крупных удалений.