При работе с распределенными информационными базами (РИБ) программисты часто сталкиваются с ситуацией, когда объект был физически удален в одной базе, но информация о его удалении «зависла» в регистрации изменений или не уходит в узлы-приемники. Стандартные инструменты, такие как типовая обработка «Регистрация изменений для обмена данными», зачастую не отображают такие записи, так как они пытаются получить представление объекта по ссылке, которой в основной таблице базы данных уже не существует.
В этой статье мы подробно разберем внутреннее устройство механизма регистрации изменений, выясним, почему удаленные объекты становятся «невидимками», и научимся извлекать информацию о них различными способами: от встроенного языка 1С до прямых запросов к СУБД.
Для начала проанализируем, как платформа 1С:Предприятие 8.3 отслеживает изменения. Для каждого объекта метаданных (справочника, документа и т.д.), включенного в состав плана обмена, система создает вспомогательную таблицу регистрации изменений. В терминах SQL эти таблицы имеют префикс _ChngRec.
Когда мы работаем с данными, возможны два принципиально разных сценария, которые часто путают:
ПометкаУдаления (или DeletionMark). Объект остается в основной таблице, его ссылка валидна. В таблице регистрации появляется запись, указывающая на существующий объект._ChngRec обязана сохраниться, иначе другие узлы системы никогда не узнают, что этот объект нужно удалить у себя.Проблема «невидимости» в консолях регистрации заключается в том, что в таблице изменений остается только GUID (уникальный идентификатор) и ссылка на узел плана обмена. При попытке стандартной консоли запросов отобразить поле Ссылка, система выполняет соединение с основной таблицей. Так как записи в основной таблице нет, мы получаем NULL или сообщение «Объект не найден», и многие универсальные обработки просто скрывают такие строки из интерфейса.
Рассмотрим, как программно получить список физически удаленных объектов, которые все еще зарегистрированы для обмена. Мы можем обратиться к виртуальной таблице изменений. Для этого используется синтаксис Справочник.ИмяСправочника.Изменения.
Разберем пример кода, который поможет нам найти такие объекты:
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Изменения.Ссылка КАК СсылкаНаОбъект,
| Изменения.Узел КАК УзелОбмена
|ИЗ
| Справочник.Номенклатура.Изменения КАК Изменения
|ГДЕ
| Изменения.Узел = &Узел";
Запрос.УстановитьПараметр("Узел", ВыбУзел);
Результат = Запрос.Выполнить().Выбрать();
Пока Результат.Следующий() Цикл
Если Результат.СсылкаНаОбъект.ПолучитьОбъект() = Неопределено Тогда
Сообщить("Найден удаленный объект: " + Результат.СсылкаНаОбъект);
КонецЕсли;
КонецЦикла;
В данном примере мы анализируем ситуацию, когда ссылка существует в таблице изменений, но метод ПолучитьОбъект() возвращает Неопределено. Это явный признак того, что объект был удален физически, но запись о необходимости передачи этого удаления в другой узел осталась.
Если ваша база работает на MS SQL Server или PostgreSQL, мы можем проанализировать ситуацию на уровне СУБД. Это самый эффективный метод, так как он позволяет увидеть «сырые» данные без влияния механизмов платформы 1С.
Выясним структуру имен таблиц. Если наш справочник называется Номенклатура, его основная таблица может называться _Reference45, а таблица регистрации изменений — _ReferenceChngRec45. Выполним LEFT JOIN между ними:
SELECT
ChRec.NodeRRef,
ChRec.DataRef,
ChRec.MessageNo
FROM
_ReferenceChngRec45 AS ChRec
LEFT JOIN
_Reference45 AS Main ON ChRec.DataRef = Main.IDRRef
WHERE
Main.IDRRef IS NULL;
Проанализируем этот запрос: мы выбираем все записи из таблицы регистрации изменений, для которых нет соответствия в основной таблице справочника (где Main.IDRRef IS NULL). Поле DataRef содержит бинарный идентификатор удаленного объекта. Это именно те данные, которые будут упакованы в сообщение обмена как команда удаления.
Чтобы окончательно убедиться в том, что система «видит» удаление, мы можем проанализировать само сообщение обмена. Рассмотрим алгоритм действий:
v8:Deletion.Внутри сообщения обмена удаленный объект выглядит примерно так:
<v8:Deletion>
<v8:ReferenceType>cfg:CatalogRef.Номенклатура</v8:ReferenceType>
<v8:Description>{GUID удаленного объекта}</v8:Description>
</v8:Deletion>
Наличие такого блока в XML подтверждает, что механизм РИБ корректно обработал физическое удаление и подготовил данные для трансляции в подчиненные или вышестоящие узлы.
В современных конфигурациях, таких как Управление торговлей 11, процесс регистрации изменений тесно связан с подсистемой обмена данными БСП. Выясним важные нюансы:
Квитирование сообщений: Запись об удалении не исчезнет из таблицы изменений сразу после выгрузки. Она будет находиться там до тех пор, пока от узла-получателя не придет подтверждение (номер сообщения в ответе должен быть больше или равен номеру сообщения, в котором ушло удаление). Если обмен односторонний или квитирование не настроено, таблицы _ChngRec могут раздуваться до огромных размеров.
Версионирование: Если в базе включено версионирование объектов, то даже после физического удаления объекта информацию о нем (кто удалил, когда и какие данные в нем были) можно попытаться извлечь из регистра сведений ВерсииОбъектов. Это полезно для расследования причин случайного удаления данных, которые уже «улетели» по РИБ.
Для удобной работы с регистрациями изменений рекомендуется использовать специализированные инструменты. Одним из наиболее мощных является Редактор изменений на узле (входит в состав инструментов разработчика от сторонних авторов, таких как DevTools). Эти инструменты отличаются от штатных тем, что:
GUID объекта.MessageNo), закрепленные за каждой записью регистрации, что критически важно для отладки проблем «зависших» изменений.Мы выяснили, что отсутствие видимых записей в стандартной консоли регистрации при наличии проблем в обмене часто связано с тем, что объект удален физически. Для диагностики следует:
.Изменения с проверкой на Неопределено._ChngRec через LEFT JOIN.v8:Deletion.Понимание этих низкоуровневых механизмов позволяет администратору или программисту 1С оперативно решать проблемы синхронизации в сложных распределенных системах.