УТ 11.3.1.127, 1С:Предприятие 8.3.8.2197. Полная РИБ. Обновил конфигурацию головного узла до 11.3.1.142. При попытке сделать синхронизацию на подчинённом узле возникает Ошибка чтения файла сообщения обмена: {Обработка.КонвертацияОбъектовРаспределенныхИнформационныхБаз.МодульОбъекта(196)}: Ошибка при вызове метода контекста (ПрочитатьИзменения): Ошибка преобразования данных XML: [sfile://C:/Users/Админ/AppData/Local/Temp/Exchange82 {441BBE86-8105-48ED-B672-78A717B9445A}/Message_B0_B1.xml][5985545,22]
Фрагмент кода возле указанной строки ниже. Строка 5985545 5-я в этом коде "...<v8md:Content>7.."
Сохранить cf из центрального узла и загрузи в подчиненный. Я обычно все же сравниваю, но потом все равно именно загружаю, чтобы сохранились все идентификаторы
(5) С этим разобрался. Сделал:
-Выгрузил cf из главной базы.
-Отвязал обработкой подчинённый узел от главного.
-Снял конфигурацию подчинённого узла с поддержки.
-Загрузил в подчинённый cf из главного. Обновление конфигурации выполнилось.
-При открытии подчинённого в режиме предприятия, выбрал "согласиться с предложением на восстановление связи с главным узлом"
Дальше хуже. Узел пытается синхронизироваться с главным и выходит та же ошибка, что и в топике. Даже если отменяешь регистрацию объектов в главном узле перед синхронизацией или делаешь "регистрацию данных для восстановления подчинённого узла РИБ" - всё равно сообщение размером ~295Мб и та же ошибка. Если убираешь сообщение из каталого обмена: "каталог не обнаружен", "Ошибка загрузки приоритетных данных из сообщения обмена."
Возможно главный узел пытается передать все изначальные "испорченные" данные, что не передались раньше? Нужно как-то его обмануть, чтобы сбросить их. Изменить номер сообщения?
Варианты решения, может кому пригодится:
1 вариант: Всё что в (6), но при открытии подчинённого в режиме предприятия, отказываемся "согласиться с предложением на восстановление связи с главным узлом". После чего удаляем синхронизацию из ЦБ. Создаём заново узлы РИБ во всех базах с теми же префиксами. В подчинённых узлах обработкой назначаем созданные синхронизации главными. Обмениваемся не выгруженными документами через обработку выгрузки XML.
2 вариант: Всё что в (6), но перед финальной попыткой подчинённого узла синхронизироваться подсовываешь изменённое сообщение. Все данные после <v8de:Version>216.0</v8de:Version> до
<v8de:Digest1> ... </v8de:Digest1>
<v8de:Digest2 ... </v8de:Digest2>
трём, а сами последние две строки заменяем аналогичными аналогичными из предыдущего сообщения из подчинённой базы - там хэш, которое потом удаляем.
3 вариант: Самый простой, им и успешно воспользовался. Делаем любое изменение в конфигурации ЦБ, сохраняем обновляем. Запускаем предприятие с параметром запуститьОбновлениеИнформационнойБазы. После этого всё благополучно синхронизируется/обновляется.
3 вариант: Самый простой, им и успешно воспользовался. Делаем любое изменение в конфигурации ЦБ, сохраняем обновляем. Запускаем предприятие с параметром запуститьОбновлениеИнформационнойБазы. После этого всё благополучно синхронизируется/обновляется.
а тебе регистрация из главного узла не важна? тогда вообще можно сделать новый узел и переподключиться именно к нему.
Можно попробовать удалить из xml сами данные конфигурации.
Но предварительно почисти кэш у пользователя, под которым обмен из главного узла запускается
Прочитав комментарий 18 в http://infostart.ru/public/65458/ посмотрел у себя журнал регистраций. Увидел последние транзакции по регистру сведений, отменил по нему регистрацию (нам он не сильно нужен на точках), и провел обмен, все получилось.
Я сделал так:
1.Прописал /ResetMasterNode в строке при открытии базы и открыл конфигуратор ( при этом он не открывается но снимается РИБ)
2.Удалил строчку /ResetMasterNode
3.Зашел в конфигуратор обновил до того же релиза
4.Зашел в предприятие и нажал восстановить (предварительно закрыв конфигуратор, если ругается на ошибки завершить работу и еще раз открыть в предприятии)
5. Если номер сообщений плана обмена поменялся, то изменил обработкой с ИТС регистрация изменений плана обмена
Этот вариант показался проще и быстрее чем предыдущие, вариант с изменением конфы не сработал база поймала обновления через РИБ и порушилась.
У меня такое сообщение Ошибка чтения файла сообщения обмена: {Обработка.КонвертацияОбъектовРаспределенныхИнформационныхБаз.МодульОбъекта(197)}: Ошибка при вызове метода контекста (ПрочитатьИзменения): Ошибка преобразования данных XML
без указания файла.
пробую третий вариант