В практике разработчика 1С иногда встречается неприятная ситуация: в журнале документов отображается строка, при нажатии на которую открывается сообщение «Объект не найден». При этом поиск по всей базе подтверждает, что физически документа с таким UUID (уникальным идентификатором) больше не существует. Попытки просто «очистить» ссылки в связанных справочниках не помогают, так как запись «застряла» именно в самой таблице журнала.
В этой статье мы подробно разберем, почему возникают такие «фантомные» записи, проанализируем внутреннее устройство платформы и рассмотрим несколько проверенных способов решения проблемы: от стандартного тестирования до принудительной реструктуризации таблиц базы данных.
Для начала проанализируем техническую сторону вопроса. Вопреки распространенному мнению, журнал документов в 1С — это не просто виртуальное представление (вьюха), собирающее данные из разных таблиц в реальном времени. На уровне СУБД (SQL Server, PostgreSQL и др.) журнал документов представляет собой отдельную физическую таблицу (обычно она имеет префикс _DocumentJournal).
Платформа 1С дублирует в эту таблицу ключевые данные из всех документов, входящих в журнал: дату, номер, тип документа, пометку удаления, состояние проведения и значения общих реквизитов. Это сделано для обеспечения высокой скорости работы: системе проще прочитать одну плоскую таблицу, чем выполнять тяжелое соединение (JOIN) десятков таблиц разных видов документов.
Рассинхронизация (когда запись в таблице документа удалена, а в таблице журнала осталась) может произойти в следующих случаях:
rphost, основная транзакция могла зафиксироваться частично.DELETE в консоли SQL, механизмы платформы 1С не смогли отработать очистку связанных таблиц.Разберем способы решения этой проблемы по шагам.
Первым делом рассмотрим стандартный механизм платформы. Если мы обнаружили «битую» ссылку, необходимо запустить процедуру Тестирование и исправление.
Выполним следующие действия:
Этот метод эффективен, но на больших базах данных он может занимать часы или даже сутки, так как платформа будет проверять абсолютно все ссылки в системе. Если время ограничено, перейдем к более быстрым методам.
Рассмотрим метод, который помог автору обсуждаемой темы. Суть заключается в том, чтобы заставить платформу 1С полностью пересоздать физическую таблицу журнала в базе данных. Когда структура таблицы меняется, 1С выгружает из нее данные, пересоздает схему и загружает данные обратно, основываясь на актуальных объектах документов.
Алгоритм действий:
Во время обновления произойдет реструктуризация таблицы _DocumentJournal. Поскольку физически документа-источника нет, при заполнении новой таблицы «фантомная» запись просто не будет создана. После этого изменения в конфигураторе можно откатить назад — лишний индекс нам не нужен, а таблица уже будет «чистой».
Проанализируем еще один интересный подход: попробовать «обмануть» систему, создав объект с тем же идентификатором GUID, который застрял в журнале.
Сначала нам нужно выяснить UUID битой ссылки. Это можно сделать программно или через навигационную ссылку. Рассмотрим пример кода, который поможет создать документ с конкретным идентификатором:
// Предположим, мы узнали UUID битой ссылки
НужныйИдентификатор = Новый УникальныйИдентификатор("550e8400-e29b-41d4-a716-446655440000");
ТипДокумента = Документы.РеализацияТоваровУслуг; // Замените на ваш тип
// Попробуем создать объект с этим GUID
НовыйДокумент = ТипДокумента.СоздатьДокумент();
НовыйДокумент.УстановитьСсылкуНового(ТипДокумента.ПолучитьСсылку(НужныйИдентификатор));
НовыйДокумент.Дата = ТекущаяДата();
НовыйДокумент.Записать();
// Теперь, когда объект физически существует и связан с журналом, удаляем его окончательно
НовыйДокумент.Удалить();
Важное замечание: как отметил автор темы, этот способ может не сработать и выдать «Ошибку индекса». Это происходит потому, что в таблице журнала запись с таким GUID уже существует в виде «мусора», и при попытке записи нового документа система пытается вставить в индекс журнала дублирующее значение. Если вы столкнулись с такой ошибкой, используйте Способ 2 (реструктуризацию).
Если ваша база работает в файловом варианте, причиной проблемы может быть повреждение внутреннего индекса файла .1CD. В этом случае стандартные средства конфигуратора могут не видеть проблему на логическом уровне.
Проанализируем шаги по исправлению файла:
C:\Program Files\1cv8\номер_версии\bin) утилиту chdbfl.exe.Утилита проверит физическую целостность таблиц и перестроит индексы, что часто помогает избавиться от «фантомов» в журналах.
Если у вас есть доступ к SQL-серверу, мы можем убедиться, что проблема именно в журнале. Выполним простой запрос (на примере MS SQL Server):
-- Поиск записи в таблице журнала по представлению ссылки
SELECT * FROM _DocumentJournalXXX
WHERE _DocumentJournalXXX._DocumentTRef = 0x... -- Здесь код типа документа
AND _DocumentJournalXXX._DocumentRRef = 0x... -- Здесь идентификатор объекта
Если запрос возвращает строку, а аналогичный запрос к основной таблице документа _DocumentYYY ничего не находит — мы имеем дело с классической рассинхронизацией. В этом случае самым безопасным и правильным методом для программиста 1С будет именно Способ 2 (изменение структуры журнала в конфигураторе), так как он задействует штатные механизмы платформы для исправления ситуации.
Подведем итог: появление битых ссылок в журналах — это следствие нарушения физической целостности данных. Самый быстрый и эффективный способ «вылечить» такой журнал без полной проверки всей базы — это кратковременное изменение его состава или свойств индексирования реквизитов, что инициирует процедуру реструктуризации таблицы.