Для тех, кто не смотрел, то есть не читал первую часть (Бессмертная регистрация объектов) - вы ничего не пропустили.
Как и в известной песне КиШ, после излечения общей проблемы, вылезла одна неприятность.
Итак: 1 центральная (серверная) база. 9 периферийных (файловых). Обмены через файлы. Здоровые файлы обмена занимают примерно 14 Кб. Периодически ЦЕНТР отправляет в одну базу сообщение 169 Кб. Внутри пара тысяч записей регистров св. ("ТаблицыГруппДоступа","ГруппыЗначенийДоступа" стандарт для БСП). Если вручную удаляешь регистрацию, то файл уменьшается до 14 Кб, но через некоторое время опять 169 Кб. Без вмешательства файл обмена периодически произвольно становиться нормальным. Отследить не просто, но есть подозрение, что вручную обменивается без проблем, а регламентный обмен 50/50. Такая проблема только для одной периферийной базой.
ТИИ делал как на центральной, так и на переферийной базах (без создания новых элементов).
Идеи кончились, кто нибудь истреблял такую нечисть?

Понял только одно. Планов обмена у тебя несколько. И если они пересекаются по данным, то забористым комбинациям несть числа. Достаточно было поменяться стратегии изменения данных.

(1) Согласен. Но обмен проходит только по одному плану. Получается, что для каждого плана свои записи таблицы регистрации. Разве есть шансы, что соседние планы обмена как-то помешают?

(2) В прошлой ветке ты сказал, что обмены идут по двум планам.

(0) так работает авторегистрация, живи с этим.
Если жить так нету больше сил, то надо запрещать автрегистрацию и рисовать общую функцию, которая будет праивльно регистрировать - если ОбменДанными.Отправитель такой-то, то не регистрировать где попало, а регистрировать только там, где надо. Это в общем виде называется иоляцией планов обмена.

(3) Да 2, просто у второго абсолютно пустой "Состав", ни один объект для него не регистрируется. Поэтому, чтобы не загромождать сообщение этими пояснениями - написал 1.

(5) значит что-то меняет этот регистр. Регзадание, например.

(1) К тому же у другого плана обмена - другие узлы. Ошибка касается определенного узла.
(6) Опять же странно, что для одного узла

(6)Пробежался глобальным поиском (проверил один регистр) - в модулях этот регистр встречается только по своему прямому назначению.

(0) 169 Кб - это вообще ниочем. А в чём проблема-то?

Фильтры в планах обмена какие есть? может фильтрует только для одного узла.

(9) 169 Кб - Архив
9,94 МБ - разархивированный файл
146800 строк
Проблема в том, что читается он в периферийной базе довольно долго. Иногда, во время чтения, Блокирует таблицы и мешает работе.

содержимое модуля планов обмена в студию

(10) Что вы имеете ввиду под фильтрами?
Правила регистрации - нет, так как используется авторегистрация.
Правила выгрузки - В правилах обмена не использовали.

(13) имею ввиду что в модуле плана обмена?

(14) Там практически пусто
В модуле объекта

Процедура ПередУдалением(Отказ)    
    ОбменВнешнимиЗаданиямиСервер.ОчиститьРегистрИсточникиВнешнихЗадач(ЭтотОбъект.Ссылка);    
КонецПроцедуры

Внутри процедуры идет работа с регистром задач.

В модуле менеджера - куча пустых заготовок функций, ничего интересного

"Такая проблема только для одной периферийной базой" - навеяло: как-то я делал "односторонний" обмен - ловил изменения объектов от подчиненного узла и регистрировал изменение в главном узле - вместо изменения, объекты из центра уходили обратно в подчиненный узел, "восстанавливая" статус кво...

Может быть тут "подобный" случай - центральная база "восстанавливает" записи, когда их удаляют/изменяют в подчиненном узле?

(0) Содержимое сообщения от этой базы рассматривал как источник такого поведения центральной базы?

(16) Это как раз содержание первой части - тогда победить получилось, удалив регистрацию изменений на периферийной базе, сейчас не помогает, и к тому же тогда изменения из периферийного узла логично пытались разойтись из центра по всем остальным базам, сейчас нет.
(17) Да, думал, что с пользователями беда, удалял записи регистра с битыми ссылками на пользователей. Идей тоже больше нет.

(7) журнал регистрации даст инфу, кто и когда записывает регистр. Может у пользователей какая-то пьяная обработка есть

(19) В Журнале единичные изменения, пару раз в месяц. Да и настоящие изменения разойдутся по всем узлам, а не только на один. Есть таки подозрение, что это баг, а не фича. И его надо именно лечить.

(20) сказочник, как ты по ЖР научился отличать единичные изменения регистров сведений от массовых?

(21) Никак не научился. Просто в ЖР на закладке Данные (в Конфигураторе), оставил галки, только на этих регистрах. В отфильтрованном ЖР увидел что за последний месяц изменения регистрировались 2 раза. 1 связан с добавлением нового пользователя, 2 - я удалял записи с битыми ссылками. Почему сказочник не понимаю.

Нет больше идей?

Ну и еще разок ап.

Предположу, что регистрация пишется не при изменении обьекта, а рри загрузки из перефирийки.
подобное есть в бп3.0

кстати регистрация может писаться и к несуществующим строкам в базе.
думаю надо копать перефирийку

(25) Согласен. Отключил в обменах загрузку данных из этой переферийки. Косяки прекратились. Вылечить переферийку не полуилось. Делали ТИИ, Загрузку/выгрузку dt, очистку регистрации изменений. После того как снова включили загрузку данных и этого узла - проблема возобновилась.

Поставь логирование на этот регистр перед записью

(27) Имеется ввиду - в ручную написать механизм логирования или в платформе есть какой-нибудь чудо-функционал.
Журнал регистрации разве этим не занимается?