Почему после Тестирования и исправления в 1С появляются битые ссылки и как их восстановить

Ситуация, когда после проведения штатной процедуры Тестирования и исправления (ТиИ) в информационной базе внезапно обнаруживаются записи с пометкой «Объект не найден», является довольно распространенной в практике администраторов и программистов 1С. Разберем подробно, почему это происходит, как найти «виновных» и, самое главное, какими способами можно вернуть утраченные данные.

Выясним причины появления битых ссылок

Рассмотрим основные сценарии, при которых ссылки на объекты (например, на элементы справочника Номенклатура) превращаются в битые. Важно понимать, что само по себе ТиИ редко «убивает» живые данные — чаще оно лишь проявляет скрытые проблемы, которые уже существовали в базе.

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

Как идентифицировать удаленные объекты через Журнал регистрации

Если клиент утверждает, что «раньше всё было хорошо», нам необходимо проверить это утверждение. Рассмотрим, как использовать Журнал регистрации (ЖР) для диагностики.

Битая ссылка в пользовательском интерфейсе выглядит как текстовая строка вида <Объект не найден> (84:bf0000155d05070311df90407a518063). Последняя часть в скобках — это GUID (уникальный идентификатор) удаленного объекта. Скопируем этот идентификатор и выполним поиск в Журнале регистрации. Если ЖР велся корректно, мы увидим события «Добавление» или «Изменение» для этого объекта. В колонке «Данные» или «Представление» часто сохраняется текстовое наименование объекта (например, «Клизма для программиста»), что позволит нам понять, что именно было удалено.

Восстановление данных из архивной копии

Если у нас есть актуальная архивная копия базы, сделанная до проведения ТиИ, мы можем восстановить объекты с сохранением их идентификаторов. Это критически важно: нам нужно не просто создать новую номенклатуру с тем же названием, а создать объект с тем же GUID, чтобы ссылки в документах «ожили».

Для этого лучше всего использовать типовую обработку «Выгрузка и загрузка данных XML» (ее можно найти на диске ИТС или в составе поставки «Конвертации данных»). Разберем алгоритм действий по шагам:

1. Запустим архивную копию базы.
2. Откроем обработку ВыгрузкаЗагрузкаДанныхXML.epf.
3. Выберем нужный справочник (например, Номенклатура) и настроим фильтр по тем элементам, которые стали битыми ссылками в рабочей базе.
4. Выгрузим данные в файл.
5. В рабочей базе откроем ту же обработку и выполним загрузку.

Поскольку обработка XML переносит объекты вместе с их внутренними идентификаторами, после загрузки битые ссылки автоматически заменятся на восстановленные объекты.

Альтернативный метод: Создание объектов через ТиИ

Если архивной копии нет, но нам нужно хотя бы вернуть базе работоспособность и понимание структуры, можно запустить Тестирование и исправление с другими настройками. Рассмотрим режим «При наличии ссылок на несуществующие объекты — Создавать объекты».

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

Программный поиск битых ссылок

Для автоматизации поиска всех битых ссылок в базе программист может использовать встроенный язык 1С. Рассмотрим пример логики поиска «битых» значений в конкретной таблице:

// Пример логики поиска битых ссылок в справочнике Номенклатура
Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	Номенклатура.Ссылка КАК Ссылка
    |ИЗ
    |	Справочник.Номенклатура КАК Номенклатура
    |ГДЕ
    |	Номенклатура.Наименование ЕСТЬ NULL"; 
    // Это один из признаков битой ссылки в запросе

Однако более универсальным методом является использование функции ПолучитьОбъект(). Проанализируем следующий подход: если Ссылка.ПолучитьОбъект() возвращает Неопределено, при этом сама ссылка не является Пустая(), то перед нами классическая битая ссылка («объект не найден»).

Рекомендации по предотвращению проблемы

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

• Всегда создаем резервную копию перед запуском ТиИ или любых групповых обработок. Это аксиома работы в 1С. При обслуживании нескольких баз для этого можно наладить автоматическое архивирование и тестирование баз 1С по расписанию.
• Используем режим «Только тестирование». Перед тем как что-то исправлять, запустим проверку без галочек «Исправлять». Проанализируем отчет и оценим масштаб трагедии.
• Очистка кэша. Иногда «Объект не найден» — это фантомная ошибка локального кэша. Перед запуском тяжелых процедур исправления попробуем очистить временные файлы пользователя.
• Анализ прав доступа. Убедимся, что «битые ссылки» не являются результатом работы RLS (Record Level Security). Иногда объект в базе есть, но у текущего пользователя нет прав на его чтение, и система отображает его как «Объект не найден».

Таким образом, появление битых ссылок после ТиИ — это сигнал о том, что в базе нарушена логическая целостность, которая копилась долгое время. Использование инструментов выгрузки-загрузки XML и внимательный анализ Журнала регистрации позволяют восстановить данные даже в самых сложных случаях.