Ошибка чтения файла сообщения обмена
Обновлено: 03.07.2024
1. Конфигурация узла распределенной ИБ не соответствует ожидаемой.
Самой распространенной ошибкой при использовании распределенных баз в 1с:Предприятие 8.x является ошибка "Конфигурация узла распределенной ИБ не соответствует ожидаемой". Связана она с рассинхронизацией конфигурации главного и подчиненного узла, возникать может по нескольким причинам, самая распространенная из них это динамическое обновление конфигурации. Рассмотрим основные пути решения данной проблемы, укажу способы по простоте их использования, сначала самые простые (но иногда не менее эффективные), потом более сложные:
Чистка кэша .
- При работе в режиме предприятия 1с кэширует метаданные для ускорения работы программы и при динамическом обновлении конфигурации использует их до момента перезапуска сеанса пользователя. При это могут возникать ситуации, когда после перезапуска программа не обновила метаданные из измененной, а продолжает использовать старые. В такой ситуации помогает очистка кэша, при новом запуске программа обновит метаданные. Очистить кэш можно множеством способов, приведу несколько из них:
- На мой взгляд самый простой из них это удаление базы из списка информационных баз и добавление заново под другим именем. При добавлении базы как новой в список информационных баз программа создаст новый каталог на диски для хранения кэшей к этой базе.
- Можно очистить базу удалив папки с кэшем. Папки храняться в зависимости от версии windows:
<каталог пользователя>\Local Settings\Application Data\1C\1Cv82
<каталог пользователя>\Application Data\1C\1Cv82
Можно воспользоваться готовым bat-файлом для удаление файлов кэша, как это описано в этой статье "Чистка кэша 1с".
Не денамическое обновление корневого узла.
- Данный метод обноружил случайно, на просторах интернета такого способа не нашел, но помогает он очень часто и в отличии от следующих способов помогает решить проблему намного быстрее и проще. Заключается он в том, что мы еще раз меняем что либо в корне конфигурации (я чаще всего меняю синоним конфигурации, например добаляя пробел в конце синонима) и делаем при этом не динамическое обновление. После этого производим еще раз обмен из главного узла с подчиненными. В большенстве случаев, хотя и не всегда к сожалению, данный метод позволяет решить ошибку рассинхронизации конфигураций. Этот способ не всегда является эффективным, но в отличии от следующих способов позволяет быстро решить данную проблему, особенно при большом количестве узлов распределенных баз.
Перенос конфигурации в распределенный узел .
Самый распространенный способ решения данной проблемы, он почти в 100% случаев помогает решить данную проблему, опять таки замечу, что почти в 100%, т.к. у меня возникали случаи, когда переносом конфигурации из главного узла в подчиненный проблема не решалась. Данный метод заключается в переносе конфигурации из главной базы в распределенную.
Последовательность действий:
- выгружаем из центральной базы конфигурацию в cf-файл;
- отвязываем переферийную базу от главного узла, вызвав команду:
- заменяем конфигурацию переферийной базы на выгруженный в первом шаге cf-файл, для этого пользуемся меню "Загрузить конфигурацию из файла".
- Привязываем переферийную базу обратно к главному узлу РИБ, вызвав команду:
где в качестве параметра передаем главный узел распределенной базы.
Для выполнение этих действий удобнее всего воспользоваться обработкой, которую можно скачать здесь (подходит для всех конфигураций на не управляемых формах, т.к. Розница 1.0 или УТ 10.3, огромное множество аналогичных можно найти на просторах инфостарта).
Подмена хэша конфигурации в файле обмена.
- Данный метод был взят из статьи Популярные ошибки РИБ. Метод на мой взгляд довольно таки сложный и длительный, поэтому я его указываю как самый последний из вариантов решения данной проблемы, его стоит использовать только лишь в том случае, если не один из выше перечисленных способов не позволил решить проблему. Его суть заключается в том, что мы заменяем хеш конфигурации в файле обмена на правильный и тем самым обманывая программу производим обмен.
Последовательность действий:
- выполняем действия из предыдущей методики;
- выгружаем из переферийной базы файл обмена, но не загружаем его в главную базу;
- выгружаем из главной базы файл обмена, но не загружаем его в переферийную базу;
- в файле обмена из главной базы заменяем блок, содержащий информацию об изменениях конфигурации и хэши (Digest1 и Digest2), на блок хэшей из файла переферийной базы (пример см. ниже).
- производим загрузку файла из 4-го пункта в переферийную базу;
- обязательно перезаписываем файл обмена из переферийной базы (2-й пункт) этот файл не должен быть загружен при обмене в главную базу.
- для проверки делаем несколько последовательных обменов.
Если при обмене используется сжатие данных, то либо отключаем сжатие, либо сначала распаковываем файл, меняем, потом запаковываем обратно и отправляем.
Блок файла обмена из главной базы:
нужно заменить на блок файла обмена из переферийной базы (обратите внимание Digest1 у файла из переферийной базы всегда равен "00000000000000000000000000000000". )
3. Ошибка преобразования данных XML.
С появлением режима совместимости 8.3.12, как вы знаете, появилась возможность распространять расширения из центрального узла в подчиненные вместе с обменом. Будем считать, что план обмена и конфигурация у вас поддерживает передачу расширений в узлы (подробнее по настройке вы можете посмотреть, например, тут).
Казалось бы, после этого достаточно просто добавить расширение в центральный узел, установить ему признак "Используется в РИБ", выполнить обмен и принять расширение в узле! Но реальность оказалась куда "интереснее".
Идентификаторы объектов расширений
Первая проблема, с которой вы можете столкнуться в центральном узле (при использовании типовой конфигурации) при выгрузке - это возможное отсутствие записей в справочнике "Идентификаторы объектов расширений", если в расширение вы добавили новые объекты (справочники, регистры сведений и т.д.). В этом случае можно выполнить обновление справочника процедурой:
К статье прикрепил готовую обработку с одной кнопкой, которая запускает выполнение этой процедуры:
Нарушение прав доступа, файл не обнаружен Params\DBNames.
Еще одна проблема, которая может изрядно испугать рядового пользователя. Не всегда, но возникает после подключения расширения, в котором добавлены новые объекты. Пользователи даже с полным правами не могут войти в 1С, хотя вы уверены, что на свои объекты вы дали права, либо чтение/запись производится в привилегированном режиме. И вообще, почему он ругается на таблицу, явно связанную с новым добавленным объектом? При этом утилита chdbfl проблем не обнаружила, да и ТиИ результатов не дало. И вот тут стоит вспомнить шутку о том, что
В любой непонятной ситуации - чисти кэш!
Да, это именно тот случай: чистим кэш и прощаемся с проблемой!
Ошибка получения данных в узле (файловая база)
Итак, расширение в центре подключили, сделали выгрузку: осталось получить данные в узле! Да проще простого! Запускаем обмен и видим следующую картину:
Ага, думаем, расширение пришло и 1С просит перезапустить сеанс! Но после перезапуска расширение не работает, а обмен так и не идет. Ладно, смотрим ЖР:
Как так? Сеанс всего один и именно из него мы пытаемся выполнить обмен! Как еще можно это сделать? Ок, дождемся запуска обмена по расписанию. Ничего не поменялось?! Ну тогда чистим кэш, делаем тестирование. Ошибок при тестировании никаких, кэш почистили, но обмен так и не идет! После чтения ИТС, списка изменений в релизах платформ, экспериментов выяснилось, что все дело в платформе! После перебора версий выяснилось, что ошибка точно присутствует в версиях 8.3.13.1690 и 8.3.14.1565, а на версии 8.3.13.1513 обмен проходит без проблем. При этом, если на узле используется клиент-серверный вариант работы, то ошибка не воспроизводится. Опять-таки, в ходе экспериментов выяснилось: первый обмен следует запускать кнопкой "Выполнить сценарий" в форме настройки сценариев обмена; причем обмен удивительным образом проходит даже на проблемных версиях платформы! Почему таким образом удается провести обмен - пока непонятно. Стоит отметить, что в центре можно использовать любую платформу: ошибок с обменом в центральном узле не обнаружили.
Напоследок
Как выяснилось позже, если у расширения стоит признак "Используется в РИБ", то оно попадает в файл обмена при каждой выгрузке! Да, даже если вы не вносили изменений в расширение, оно все равно будет каждый раз выгружаться в узел! Так что если у вас проблемы с интернетом на точках, то самое время заняться оптимизацией состава расширения!
Следует помнить: если вы добавили новые объекты в расширении, у вас настроен РИБ через план обмена, который поддерживает передачу расширений в узлы, то обмен у вас не заработает до тех пор, пока вы у расширения не поставите признак "Используется в РИБ"!
А если вы еще не перешли на режим совместимости 8.3.12+?
Надеюсь, данная статья поможет вам сэкономить массу времени нервов! Буду рад дополнить статью также вашими замечаниями, инструкциями и "находками" по данной теме!
Тестирование выполнялось на конфигурации 1С:Розница 2.2.11.29 и платформах 8.3.13.153, 8.3.13.1690 и 8.3.14.1565
РИБ и расширения: обновление идентификаторов метаданныхСпециальные предложения
Имеется в виду ссылочные объекты?
У меня в расширении есть добавленные объекты (формы), признак использования РИБ отключен, синхронизация выполняется. Расширения в узлах обновляю вручную.
Что касается полной передачи расширения в РИБ, это и ожидалось, там просто иного не предусмотрено, ровно как и в моём решении
Ну можно же было сделать проверку по контрольной сумме: поменялась - выгружаем. Думаю, это дело времени (5)А от куда главная база узнает контрольную сумму? Хотя конечно можно было сделать, как я предлагал в своей статье, это при выгрузке в центральную базу, добавлять хеш-сумму расширение, а от неё бы уже центральная база проверяла и узнавала, надо менять расширение или нет. Но 1Сники видимо решили по проще сделать. при выгрузке в центральную базу, добавлять хеш-сумму расширение
1С вроде сейчас так и делает. К сожалению, сейчас нет РИБ под рукой, но в XML был узел с именем "DigestExtension" или как-то так (7) Тогда странно что каждый раз выгружает. В моём кстати решении, там на сервер передается хеш сумма расширения и сервер тем самым узнает что надо передавать расширение клиенту или нет. Но вот разностная выгрузка средствами языка к сожалению не возможна. (8) да с разностной выгрузкой ладно, в большинстве случаев расширение не так много весит. Надо будет повнимательней последить за хэшем расширения в файле обмена. (9) Я как то анализировал эти хеши. Была ситуация, когда хеш расширения в центральной базе не совпадал с хешем расширения в периферийной базе. Это получилось из-за того, что некий узел конфигурации-расширения из центральной базы не передавался в периферийную. Возможно этот узел использовался в предыдущих версиях платформы, а в новой версии про него забыли и он просто лежит там как мусор. Если взять расширение из периферийной базы и загрузить в центральную, то хеши расширений начинают совпадать. Я надеялся, что после совпадения хешей расширение конфигурации перестанет каждый раз передаваться в периферийную базу, но оно всё равно передаётся. Ну хоть работает, уже хорошо. Большое вам человеческое СПАСИБО! Предлагаю сделать свой bugboard платформы 1С на инфостарте. Каждое обновление платформы как игра в рулетку или взлетит или нет( (13) зачем плодить сущности?
От этого будут быстрее ошибки исправлять?
Ставлю признак "Используется в РИБ", при попытке обмена ошибка в ЦУ:
Что с это значит?
(16) Похоже, что загрузили расширение в пользовательском режиме, но сеанс не перезапустили.(17) Загружал в конфигураторе.
для чистоты: завершил все сеансы - удалил расширение в конфигураторе - перезапустил 1С - добавил расширение в конфигураторе с признаком "Используется в РИБ" - запускаю обмен в режиме предприятия - та же ошибка.
(18) та же история 8.3.13.1690, 8.3.14.1630Работает через кнопку сценарий (19) Через сценарий обмен так же не взлетает
По крайней мере в 8.3.13.1644 . (20) Решилось удалением всех расширений в конфигураторе (установленных до обновления платформы) и добавлением их по новой. Обмен пошел сразу по кнопке Синхронизировать.
Решение подойдет в случае, если в расширениях нет собственных документов и справочников. (21)Платформа 8.3.13.1644
1. Подтверждаю, если в расширении не добавлены объекты из расширяемой конфигурации (или не добавлены новые объекты), то обмен работает по кнопке "Синхронизировать".
2. Подтверждаю, вывод статьи: если в расширении добавлены новые объекты метаданных, тогда первую синхронизацию с Узлами нужно делать по кнопке "Синхр. по сценарию", тогда расширение мигрирует в удаленную базу. После этого перезапускаем базу - чтобы принялись изменения расширения и снова жмем "Синхр. по сценарию" - в этот этап "подхватываются" уже данные. Да, если не перезапустить базу, то можно увидеть, вернее, не увидеть записи для заимственных в расширение объектов. При последующих синхронизаций, лучше синхронизировать "по сценарию", а то, вдруг обновление прилетит. Да и пользователей нужно учить, если синхронизация выполнена с ошибкой, пускай перезапускают базу и снова синхронизируются.
Как-то так.
Всё это ерунда. Пока не исправят баг с платформой счастья в РИБ не ищи. Пляски с бубном помогают каждому по своему. У нас 2 сервера для 1) 8.3.14.1565 пока танцевали с бубном каким то чудесным образом из файлов обмена пропали данные по расширениям. Если раньше есть расширение в ЦБ, то в файле выгрузки идут строки
<v8de:ConfigurationExtension>
<v8de:Id>645b2314-4ade-11e9-8d9e-708bcda98ec4</v8de:Id>
<v8de:Name>ОстаткиИЦеныВПодборе</v8de:Name>
то сейчас их нет. И обмен идёт отлично. Как так получилось но я рад до следующего обновления платформы)
2) 8.3.14.1630 Здесь не помогло не чего. Так и делаем обмен через сценарий.
P.S. пока танцевал с бубоном заметил такую вещь.
Если ЦБ 8.3.14 а ПБ 8.3.13 обмен не идёт не при каких условиях, так как в файле обмена меняются строки
<v8de:Version>216.0</v8de:Version>
<v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
<v8de:Digest2 v2="57881d97074ef04efe7be54c9c51d7d2" Extensions="0000000000000000000000000000000000000000">9d1874 89ecad40d6c652763c4f4f5ac8</v8de:Digest2>
Где то на форуме многие страдали от этой проблемы. Может кому поможет.
На сайте багборда не нашел соответствующей инфы (25) Да. У меня РИБ на 2х серверах на 8.3.14.1694 взлетел. На данный момент полёт нормальный. Уже даже обновил розницу до 2.2.12.хх
Ошибка на платформе: "8.3.13.1865"
Розница: "2.2.11.24"
Напиши, потом, как дела с этой платформой у Тебя))
Да обновление платформы исправляет ситуацию, спасибо. (30) На 8.3.14.1779 точно осталась только проблема с первоначальной загрузкой расширения (либо при загрузке обновления расширения) - для решения см. пункт "Ошибка получения данных в узле" (31) расширение передаешь из центральной базы в переферийные? (32) да. При первой передаче или при изменениях расширения в центре - в узле изменения приходится принимать через кнопку "выполнить сценарий"; потом обмен проходит без проблем (29) Обновил розницу до 2.2.12.30 версия платформы 8.3.13.1865 обмен на узле РИБ возможен только через кнопку "Выполнить сценарий" и когда в базе сидит один пользователь. Как только подключается второй пользователь сразу идет ошибка "База данных заблокирована" Помогает обновление платформы решить данную ошибку? (35) к базе подключаются два пользователя на одном компьютере (36)Платформа 8.3.14.1630, Розница 2.2.13.12, файловая периферийная - та же ерунда. Обмен работает только если вручную нажать "Выполнить сценарий". В центральной все ОК. (37) решил в правилах отключить передачу расширений в РИБ, проверил на тестах - обмен работает (38) Так да, работает без проблем. А если в расширение добавить новые объекты (регистр, справочник и т.п.), то РИБ не будет работать со снятой галкой "Используется в РИБ" у такого расширения (39) а других вариантов пока не вижу, к сожалению не всегда есть возможность сделать обмен что бы на периферийной базе работал один человек. Пока идет обмен, обычно еще и торговать надо. (39) Именно так. Если в расширении есть новые объекты или изменены имеющиеся объекты на уровне данных, то расширение придется включать в обмен, без этого на периферийной базе не будут загружаться пакеты
Читайте также: