Обмен РИБ, Ошибка преобразования данных XML
УТ 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.."
</v8md:External>
<v8md:External>
<v8md:Name>74cb37ec-41ca-4785-9d1e-9e13f1f4d2db.9</v8md:Name>
<v8md:Version>00bfd3a4-d0f8-4b0a-aeb4-30169645f584</v8md:Version>
<v8md:Content>77u/ezcsMSwxNTAsDQp7MTAwLGUwOTUzNGUzLWFjNmUtNDJhNi04
YjIwMDg5YX0sDQp7MCwNCnswLA0KeyJCIiwwfSwwfQ0KfSwNCnswLGNmM2Rk
LWFjYzctNGY0NC1iYTA4LTFiOGJjOTc3NTAzZX0sDQp7MCwNCnswLA0KeyJC
fSwwfQ0KfSwNCnswLGEzMzA2MDFkLTk0ZjQtNGNjOC1iZDQ1LWEzOTAzNGJj
Mn0sDQp7MCwNCnswLA0KeyJCIiwxfSwwfQ0KfSwNCnswLGIyOWJjNTU3LTg2
Где искать ошибку?
Фрагмент кода возле указанной строки ниже. Строка 5985545 5-я в этом коде "...<v8md:Content>7.."
</v8md:External>
<v8md:External>
<v8md:Name>74cb37ec-41ca-4785-9d1e-9e13f1f4d2db.9</v8md:Name>
<v8md:Version>00bfd3a4-d0f8-4b0a-aeb4-30169645f584</v8md:Version>
<v8md:Content>77u/ezcsMSwxNTAsDQp7MTAwLGUwOTUzNGUzLWFjNmUtNDJhNi04
YjIwMDg5YX0sDQp7MCwNCnswLA0KeyJCIiwwfSwwfQ0KfSwNCnswLGNmM2Rk
LWFjYzctNGY0NC1iYTA4LTFiOGJjOTc3NTAzZX0sDQp7MCwNCnswLA0KeyJC
fSwwfQ0KfSwNCnswLGEzMzA2MDFkLTk0ZjQtNGNjOC1iZDQ1LWEzOTAzNGJj
Mn0sDQp7MCwNCnswLA0KeyJCIiwxfSwwfQ0KfSwNCnswLGIyOWJjNTU3LTg2
Где искать ошибку?
По теме из базы знаний
- Популярные ошибки РИБ и способы их исправления. Часть 2. Ошибка преобразования данных XML
- Универсальный редактор реквизитов объектов. Мультиобработчик
- Ошибки РИБ и как с ними бороться
- Создание в 1С 7.7 XML в формате EnterpriseData (универсальный формат обмена), версия 1.5. Инструкции и примеры переноса данных из устаревшей конфигурации 1С 7.7 в любую современную 1С 8.3, поддерживающую EnterpriseData, через Конвертацию данных 3
- У вас "Ошибка преобразования данных XML" или "Error transforming XML data"? Решение
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(5) С этим разобрался. Сделал:
-Выгрузил cf из главной базы.
-Отвязал обработкой подчинённый узел от главного.
-Снял конфигурацию подчинённого узла с поддержки.
-Загрузил в подчинённый cf из главного. Обновление конфигурации выполнилось.
-При открытии подчинённого в режиме предприятия, выбрал "согласиться с предложением на восстановление связи с главным узлом"
Дальше хуже. Узел пытается синхронизироваться с главным и выходит та же ошибка, что и в топике. Даже если отменяешь регистрацию объектов в главном узле перед синхронизацией или делаешь "регистрацию данных для восстановления подчинённого узла РИБ" - всё равно сообщение размером ~295Мб и та же ошибка. Если убираешь сообщение из каталого обмена: "каталог не обнаружен", "Ошибка загрузки приоритетных данных из сообщения обмена."
Возможно главный узел пытается передать все изначальные "испорченные" данные, что не передались раньше? Нужно как-то его обмануть, чтобы сбросить их. Изменить номер сообщения?
-Выгрузил cf из главной базы.
-Отвязал обработкой подчинённый узел от главного.
-Снял конфигурацию подчинённого узла с поддержки.
-Загрузил в подчинённый cf из главного. Обновление конфигурации выполнилось.
-При открытии подчинённого в режиме предприятия, выбрал "согласиться с предложением на восстановление связи с главным узлом"
Дальше хуже. Узел пытается синхронизироваться с главным и выходит та же ошибка, что и в топике. Даже если отменяешь регистрацию объектов в главном узле перед синхронизацией или делаешь "регистрацию данных для восстановления подчинённого узла РИБ" - всё равно сообщение размером ~295Мб и та же ошибка. Если убираешь сообщение из каталого обмена: "каталог не обнаружен", "Ошибка загрузки приоритетных данных из сообщения обмена."
Возможно главный узел пытается передать все изначальные "испорченные" данные, что не передались раньше? Нужно как-то его обмануть, чтобы сбросить их. Изменить номер сообщения?
Варианты решения, может кому пригодится:
1 вариант: Всё что в (6), но при открытии подчинённого в режиме предприятия, отказываемся "согласиться с предложением на восстановление связи с главным узлом". После чего удаляем синхронизацию из ЦБ. Создаём заново узлы РИБ во всех базах с теми же префиксами. В подчинённых узлах обработкой назначаем созданные синхронизации главными. Обмениваемся не выгруженными документами через обработку выгрузки XML.
2 вариант: Всё что в (6), но перед финальной попыткой подчинённого узла синхронизироваться подсовываешь изменённое сообщение. Все данные после <v8de:Version>216.0</v8de:Version> до
<v8de:Digest1> ... </v8de:Digest1>
<v8de:Digest2 ... </v8de:Digest2>
трём, а сами последние две строки заменяем аналогичными аналогичными из предыдущего сообщения из подчинённой базы - там хэш, которое потом удаляем.
3 вариант: Самый простой, им и успешно воспользовался. Делаем любое изменение в конфигурации ЦБ, сохраняем обновляем. Запускаем предприятие с параметром запуститьОбновлениеИнформационнойБазы. После этого всё благополучно синхронизируется/обновляется.
1 вариант: Всё что в (6), но при открытии подчинённого в режиме предприятия, отказываемся "согласиться с предложением на восстановление связи с главным узлом". После чего удаляем синхронизацию из ЦБ. Создаём заново узлы РИБ во всех базах с теми же префиксами. В подчинённых узлах обработкой назначаем созданные синхронизации главными. Обмениваемся не выгруженными документами через обработку выгрузки XML.
2 вариант: Всё что в (6), но перед финальной попыткой подчинённого узла синхронизироваться подсовываешь изменённое сообщение. Все данные после <v8de:Version>216.0</v8de:Version> до
<v8de:Digest1> ... </v8de:Digest1>
<v8de:Digest2 ... </v8de:Digest2>
трём, а сами последние две строки заменяем аналогичными аналогичными из предыдущего сообщения из подчинённой базы - там хэш, которое потом удаляем.
3 вариант: Самый простой, им и успешно воспользовался. Делаем любое изменение в конфигурации ЦБ, сохраняем обновляем. Запускаем предприятие с параметром запуститьОбновлениеИнформационнойБазы. После этого всё благополучно синхронизируется/обновляется.
(8)
Спасибо за третий вариант мне помог.
3 вариант: Самый простой, им и успешно воспользовался. Делаем любое изменение в конфигурации ЦБ, сохраняем обновляем. Запускаем предприятие с параметром запуститьОбновлениеИнформационнойБазы. После этого всё благополучно синхронизируется/обновляется.
Спасибо за третий вариант мне помог.
а тебе регистрация из главного узла не важна? тогда вообще можно сделать новый узел и переподключиться именно к нему.
Можно попробовать удалить из xml сами данные конфигурации.
Но предварительно почисти кэш у пользователя, под которым обмен из главного узла запускается
Можно попробовать удалить из xml сами данные конфигурации.
Но предварительно почисти кэш у пользователя, под которым обмен из главного узла запускается
Я сделал так:
1.Прописал /ResetMasterNode в строке при открытии базы и открыл конфигуратор ( при этом он не открывается но снимается РИБ)
2.Удалил строчку /ResetMasterNode
3.Зашел в конфигуратор обновил до того же релиза
4.Зашел в предприятие и нажал восстановить (предварительно закрыв конфигуратор, если ругается на ошибки завершить работу и еще раз открыть в предприятии)
5. Если номер сообщений плана обмена поменялся, то изменил обработкой с ИТС регистрация изменений плана обмена
Этот вариант показался проще и быстрее чем предыдущие, вариант с изменением конфы не сработал база поймала обновления через РИБ и порушилась.
1.Прописал /ResetMasterNode в строке при открытии базы и открыл конфигуратор ( при этом он не открывается но снимается РИБ)
2.Удалил строчку /ResetMasterNode
3.Зашел в конфигуратор обновил до того же релиза
4.Зашел в предприятие и нажал восстановить (предварительно закрыв конфигуратор, если ругается на ошибки завершить работу и еще раз открыть в предприятии)
5. Если номер сообщений плана обмена поменялся, то изменил обработкой с ИТС регистрация изменений плана обмена
Этот вариант показался проще и быстрее чем предыдущие, вариант с изменением конфы не сработал база поймала обновления через РИБ и порушилась.
У меня такое сообщение Ошибка чтения файла сообщения обмена: {Обработка.КонвертацияОбъектовРаспределенныхИнформационныхБаз.МодульОбъекта(197)}: Ошибка при вызове метода контекста (ПрочитатьИзменения): Ошибка преобразования данных XML
без указания файла.
пробую третий вариант
без указания файла.
пробую третий вариант
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот