Популярные ошибки РИБ и способы их исправления. Часть 1. Конфигурация узла распределенной ИБ не соответствует ожидаемой
Задачи пользователя - Корректировка данных
Бесплатные
ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Узнавайте о новых бесплатных решениях в нашей телеграм-группе Инфостарт БЕСПЛАТНО
| Наименование | Скачано | Бесплатно |
|---|---|---|
|
УстановкаГлавногоУзлаРИБ.epf
.epf 6,19Kb
6926
|
6926 | Скачать бесплатно |
Вы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
Для начала привожу список используемых мной сокращений:
- РИБ - распределенная информационная база
- ЦБ - центральная база, корневой узел РИБ
- УБ - удаленная база, БД удаленного узла РИБ
По собственному опыт могу сказать, что сталкивался с двумя причинам возникновения ошибки:
- во время приёма файла сообщения в УБ "упала" база, в связи с чем, видимо, и произошла разсинхронизация между конф. ЦБ и УБ;
- под MSSQL клиент загрузил копию рабочей базы и не выключил в копии регл. задания автообмена, в результате часть сообщений в удаленные узлы формировалась из рабочей БД, а часть из копии, что и привело рассинхронизации конфигураций
Есть также мнение, что к этой ошибке приводит использование механизма динамического обновления базы. Здесь есть сомнения, потому как с одной стороны динамическое обновление никогда не затрагивает структуры БД, а механизмы РИБ всё-таки работают именно со структурой БД, а не с прикладной её частью, тем не менее в РИБ используется механизм формирования цифровой подписи версии конфигурации (в дальнейшем буду называть её для сокращения хэшем), и при изменении прикладной части хэш естественно обязан пересчитаться. Не буду ни отрицать этого, ни утверждать, т.к. если и сталкивался с этой ситуацией, то явных доказательств этого не нашел.
Для исправления использую 2 методики, в зависимости от ситуации.
ПЕРВАЯ МЕТОДИКА
Первая (самая распространенная) неоднократно упоминается и в партнерской конференции, и на прочих интернет-ресурсах связанных с 1С. Применяется в большинстве случаев, когда несмотря на сообщение о расхождених конфигураций, при сравнении вручную выдается, что они идентичны.
Последовательность действий:
- выгружаем из ЦБ cf-файл;
- отвязываем УБ от РИБ (метод УстановитьГлавныйУзел, готовую обработку можно найти в приложении или в других публикациях);
- заменяем конф. УБ на выгруженный в первом шаге cf-файл, для этого пользуемся меню "Загрузить конфигурацию из файла" (а не сравнением-объединением!!!);
- восстанавливем признак РИБ для УБ.
В большинстве случаев этих действий более чем достаточно, что восстановить обмен, но не всегда...
ВТОРАЯ МЕТОДИКА
Применяется в случае, если первая методика не сработала, а выгрузить заново узел не представляется возможным.
Предыстория: у клиента настраивали каскадную РИБ и ошибка возникла в первом уровне каскада (второй уровень всё это время работал безупречно). Разработка конфигурации велась совместно с IT-службой клиента и с момента возникновения ошибки конфигурация ЦБ успела несколько раз поменяться. Вариант с откатом изменений не рассматривался даже в принципе, т.к. потеря части данных и остановка работы нескольких подразделений были совершенно неприемлимы. Первый вариант исправления ошибки каких-либо ощутимых результатов не дал. В связи со чем пришлось искать другие пути решения.
Пришла мысль попробовать подменить хэши файлов конфигураций непосредственно в XML-файлах обмена. Описание структуры файла обмена из книги "Профессиональная разработка в системе 1С:Предприятие 8" дало слабое представление о формировании цифровых подписей конфигураций и изменений в них, но определило направление поиска: значения Digest1 и Digest2. Всё остальное выяснял чисто эмпирическим путём (то бишь методом проб и ошибок), но закономерность установить таки получилось.
Тестовые эксперименты прошли удачно. На рабочих базах тоже всё прошло благополучно.
Итак, последовательность действий:
- выполняем действия 1 - 4 первой методики;
- выгружаем из УБ файл обмена, но не загружаем его в ЦБ;
- выгружаем из ЦБ файл обмена, но не загружаем его в УБ;
- в файле обмена из ЦБ заменяем блок, содержащий информацию об изменениях конфигурации и хэши (Digest1 и Digest2), на блок хэшей из файла УБ (пример см. ниже)
- производим загрузку файла из 4-го пункта в УБ;
- обязательно перезаписываем файл обмена из УБ (2-й пункт)! этот файл не должен быть загружен при обмене в ЦБ!
- для проверки делаем несколько последовательных обменов.
Если при обмене используется сжатие данных, то либо отключаем сжатие, либо сначала распаковываем файл, меняем, потом запаковываем обратно и отправляем.
Блок файла обмена из ЦБ
<v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">
<v8de:Version>106.0</v8de:Version>
...здесь идут блоки описания изменений конфигурации...
<v8de:Digest1>1cf680807e97a5dc0d1ed7f901b07392</v8de:Digest1>
<v8de:Digest2>038211651cf680807e97a5dc0d1ed7f9</v8de:Digest2>
</v8de:Config>
нужно заменить на блок файла обмена из УБ (обратите внимание Digest1 у файла из УБ всегда равен "00000000000000000000000000000000"!!!)
<v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">
<v8de:Version>106.0</v8de:Version>
<v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
<v8de:Digest2>11651cf680807e97a5dc0d1ed7f901b0</v8de:Digest2>
</v8de:Config>
Перечисленные действия необходимо выполнять с предельной осторожностью, некорректная последовательность чревата полной неработоспособностью РИБ. Поэтому перед этими действиям создание резервных копий ОБЯЗАТЕЛЬНО!
В остальном могу только пожелать удачи!
Вступайте в нашу телеграмм-группу Инфостарт
См. также
Перенос данных 1C Разработчик 1С:Предприятие 8 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)
Перенос документов, начальных остатков и справочной информации из УПП 1.3 в ERP 2 | из УПП 1.3 в УТ 11 | из УПП в КА 2 | Правила конвертации (КД 2) | Более 360 предприятий выполнили переход с использованием этого продукта! | Сэкономьте время - используйте готовое решение для перехода! | Позволяет перенести из УПП 1.3 в ERP / УТ 11 / КА 2 всю возможную информацию | В переносе есть фильтр по организации и множество других опциональных параметров выгрузки | Есть несколько алгоритмов выгрузки остатков на выбор
58000 руб.
04.08.2015 194769 479 310
Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Разработчик 1С:Предприятие 8 1С:Комплексная автоматизация 1.х 1С:Управление производственным предприятием 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Платные (руб)
Перенос данных из 1С:Управление производственным предприятием 1.3 в 1С:Бухгалтерия предприятия 3.0 с помощью правил обмена | Можно выполнить переход с УПП на БП 3 или запускать выгрузку данных за выбранный период времени | Переносятся документы, начальные остатки и вся справочная информация | Есть фильтр по организации и множество других параметров выгрузки | Поддерживается несколько сценариев работы: как первичный полный перенос, так и перенос только новых документов | Перенос данных возможен в "1С: Бухгалтерия 3.0" версии ПРОФ, КОРП или базовую | Переход с "1С: УПП1.3" / "1С:КА 1.1" на "1С:БП3.0" с помощью правил конвертации будет максимально комфортным! | Можно бесплатно проверить перенос на вашем сервере!
50050 руб.
25.02.2015 192534 383 296
SALE! 10%
Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Разработчик 1С:Предприятие 8 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Россия Платные (руб)
Правила в универсальном формате обмена для ERP 2.5, КА 2.5, УТ 11.5, БП 3.0, Розница, УНФ, для последних версий конфигураций. Ссылки на другие конфигурации в описании публикации. Правила совместимы со всеми другими версиями конфигураций новыми и старыми, поддерживающими обмен и синхронизацию в формате EnterpriseData. Не требуется синхронного обновления правил после обновления другой конфигурации, участвующей в обмене. Типовой обмен через планы обмена кнопкой Синхронизация вручную или автоматически по расписанию, или вручную обработкой.
27633 руб.
12.06.2017 165013 1009 329
Перенос данных 1C Взаиморасчеты Оптовая торговля Логистика, склад и ТМЦ Файловый обмен (TXT, XML, DBF), FTP Системный администратор Разработчик 1С:Предприятие 8 1С:Управление торговлей 10 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Управленческий учет Платные (руб)
Можно проверить до покупки, оставьте заявку! Воспользовались более 268 компаний! Перенос данных из УТ 10.3 в УТ 11 | из УТ 10.3 в КА 2 | из УТ 10.3 в ERP. Решение для перехода с УТ 10.3. Можно перенести начальные остатки, нормативно-справочную информацию и все возможные документы. При выгрузке можно установить отбор по периоду, организациям и складам.
50200 руб.
24.04.2015 211440 186 254
SALE! 10%
Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Разработчик 1С:Предприятие 8 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 Бухгалтерский учет Управленческий учет Платные (руб)
Переносите справочную информацию, остатки и документы из УПП 1.3 в ERP 2.6 и КА 2.6 с помощью готовых правил. Переносится более 60 видов документов. Простой интерфейс и понятные настройки.
42000
37800 руб.
24.06.2020 73140 108 35
SALE! 10%
Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Разработчик 1С:Предприятие 8 1С:Управление производственным предприятием 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Управленческий учет Платные (руб)
Переносите справочную информацию, остатки и документы из УПП 1.3 в Бухгалтерию 3.0 с помощью готовых правил. Переносится более 50 видов документов. Простой интерфейс и понятные настройки.
42000
37800 руб.
15.12.2021 37117 268 68
Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Системный администратор Разработчик 1С:Предприятие 8 1С:Комплексная автоматизация 1.х 1С:Управление торговлей 10 1С:Управление производственным предприятием Россия Платные (руб)
Регулярный обмен, выгрузка, перенос из КА 1.1, УПП 1.3, УТ 10.3 для обмена с любыми конфигурациями, поддерживающими обмен в формате EnterpriseData (КД3) - БП 3.0, ERP, КА 2, УТ 11, Розница 3, УНФ 3 и другими. Правила для старых и доработанных конфигураций не требуют синхронного обновления и совместимы с новыми и будущими конфигурациями. Обмен по расписанию, через папку, FTP, почту.
27572 руб.
18.02.2016 209246 686 559
Перенос данных 1C Файловый обмен (TXT, XML, DBF), FTP Разработчик 1С:Предприятие 8 1С:Комплексная автоматизация 1.х 1С:Управление производственным предприятием 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Платные (руб)
Правила переноса кадровых и расчетных данных и справочной информации из "1С:УПП1.3" или "1С:КА 1.1" в "1С:ЗУП 3.1 | Разработан в формате КД 2 (правила конвертации данных) | При выгрузке есть фильтр по организациям | Обновляется при выходе новых релизов 1С | Развитие алгоритмов | Расчетные документы переносятся в документ "Перенос данных" | Создаются документы "Начальная штатная расстановка" и "Начальная задолженность по зарплате", переносятся кадровые документы
58000 руб.
29.10.2018 64467 86 137
А можно ли программно из 1С получить хэши (Digest1 и Digest2) и версию (Version)? Или это информация для внутреннего использования в 1С?
всё возможно, но для этого нужно знать алгоритм вычисления :) а Version - та что хранится в конфигурации ?
её можно для этого можно использовать различные инструменты например EI, или доработать мою обработку, которая сохраняет cf из бд.
там, правда, Андрей предлагает удалять/восстанавливать узел (на мой взгляд, чтобы сбросить регистрацию проще воспользоваться обработкой "РегистрацияИзмененийДляОбмена"), что в моём случае было совершенно неприемлемо (все изменения должны были дойти до своих адресатов)...
>>что в моём случае было совершенно неприемлемо (все изменения должны были дойти до своих адресатов)...
для того что бы не потерять регистрацию в случаи неких манипуляций с узлом достаточно создать еще один узел как хранилище изменений - перелить из нужного узла регистрацию изменений. далее сделать все с ним что нужно и перелить регистрацию обратно.
если узлов много можно процесс автоматизировать.
2. в центральной ИБ создать новый узел плана обмена, соответствующий удаленному узлу (код узла должен соответствовать удаленному на первом шаге);
суть - очистить таблицу регистрации изменений... для чего это нужно - для меня так и осталось загадкой (потом же хлопот не оберешься чтобы синхронизировать узлы), а в своем комменте я просто предложил более простой вариант проведения этой операции...
Получил:
ПланыОбмена.УстановитьГлавныйУзел(ГлавныйУзел);
по причине:
Недопустимое значение параметра (параметр номер '1')
Что делаю не так?
- Главный узел ищут в УФ так:
Если хотите снять главный узел, то используйте ПланыОбмена.УстановитьГлавныйУзел(Неопределено)
Если установить - то, например, так ПланыОбмена.УстановитьГлавныйУзел(ПланыОбмена.ИмяВашегоОбмена.НайтиПоКоду("КД"));
. Учтите, что сюда можно ставить узлы только из тех планов, у которых в свойствах стоит галочка "Распределенная"
ХМ.. работает только для старых версий Розницы
Искать главный узел надо так:
ГлавныйУзел = ПланыОбмена.ГлавныйУзел();Устанавливать главный узел надо так:
// ВыбУзел - реквизит обработки с типом ПланОбменаСсылка
ПланыОбмена.УстановитьГлавныйУзел(ВыбУзел);А вот хаотичные динамические обновления из-за несогласованного регламента применения изменений на рабочей базе вполне могут быть такой причиной. Особенно если узлов много, а вы не следите за тем, что подтверждения о принятии изменений с узлов доходят до центральной БД.
Устанавливайте жёсткий регламент наката изменений на рабочую базу, и по возможности включайте в настройках узлов галочку "Выгружать только при успешной загрузке".
Вот у меня тоже абсолютно уникальная ситуация, один узел УБ работает нормально, создал еще один, и при первом же обмене пишет такую чушь. Все проведенные действия спасали только на один раз загрузить в УБ и все потом опять по новой. Заного создаю образ, загружаю конфу, вообще ничего не помогает, пишет о несоответствии и в Уб и в ЦБ...
Уже пробовал в ЦБ выгрузить начальный образ для этого узла, перенес, при первом же обмене опяь ошибка не соответствие ожидаемой!
Что делать????!!!!
Отдельное спасибо NewNick, интересный способ насчет узла с копированием регистрации изменений.
В конфигураторе пункт меню "Загрузить конфигурацию из файла" неактивен, хотя конфигурация открыта. Как убедиться, что метод УстановитьГлавныйУзел сработал? Может в этом дело?
Все конфигурация сама обновляется.
У меня , например, запуск 1с стоит на расписание под событием обмен при запуске под определенным пользователем.
В главной конфа обновилась. На перефирии конфа вывалилась, но перед этим обновилась и далее конфа уже запустилась обновленная.
Сперва позволю себе процитировать вот эти строки автора статьи:
Смею заверить, автор ошибается. Лично на своей шкуре обжигался этой хренью (динамическим обновлением).
Зарекался..... Но, очередной аврал и ... согрешил.
Итог: при очередном обновлении все нижестоящие узлы стали раком.
РЕШЕНИЕ: Испробовал метод №1 - ранее помогал безотказно - НЕ помогло!
Долго танцевал с бубном примеряя на себя метод №2 - результат не утешителен: нижестоящие базы стали кушать входящие данные, а вот Центральный узел - обратно обмены не принимал.
МОЕ РЕШЕНИЕ:
1. Снял ЦБ с поддержки.
2. Взял cf-ник ЦБ, который был "до динамического обновления". Загрузил его в конфигурацию ЦБ.
Обновил конфигурацию БД ЦБ
3 Произвел выгрузку из ЦБ
4. Произвел повторную загрузку в Распределенный узел. (прошел на ура!!!)
5. Далее.... .все пошло по накатанной.
6. Все действия 1-4 повторил для остальных узлов.
ps: данному методу не помешали даже предыдущие танцы со способом №1 и №2.
(отдельное спасибо что выделили цветом, иначе боюсь пропустил бы)
1. Создаем новую базу идентичного релиза.
2. Переносим в него СРАВНЕНИЕМ И ОБЪЕДИНЕНИЕМ доработки из ЦБ.
3. переносим с помощью Универсальной выгрузкой загрузкой XML все данные.
4. Старую базу в архив. Работаем в новой. Узлы создаем заново.
К этому я пришел после того, как испробовал все варианты, описанные здесь и в других источниках.
P.S. Изначально ЦБ крутилась на PostgreSQL. Обмен естественно не выполнялся. И даже работа в файловом варианте позже не давала положительный результат.
Всем удачи!
Это ошибка платформы. По предварительным данным исправлена в версии 8.2.18.108.
50.grap
Понятно как решать проблему. А вот из-за чего она случается не очень понятно... У меня такая ситуация возникла после обновления конфигурации БП ред. 2.0.47.7 (типовая, на поддержке). Причем пробовал обновлять и через конфигуратор, и через 1сПредприятие, в пользовательском режиме. Написал в 1с - жду ответа...
Добрый день! У нас та же проблема с ред.2.0.47.7 -причем у нас несколько разных юр.лиц с РИБами -и везде обмен перестает работать после обновления ЦБ на 2.0.48.9. Мы-простые ,скромные пользователи :))) и никак не можем решить эту задачку. Помогите, пожалуйста, по-шагово!!!
3 метод.
1.В ЦБ выгрузить конфигурацию.
2.Снять ЦБ с поддержки.
3.В ЦБ "Загрузить конфигурацию из файла", (только что выгруженную.)
ну а дальше по 2 методу.
Только таким способом все заработало.
Немного присмотревшись понял, что при снятии конфы с поддержки и проведения выгрузки информации, то тот кусок кода, который необходимо менять во втором пункте самостоятельно обнуляется. Т.е. регистрация изменения конфигурации к конфигурации поставщика сбрасывается.
Спасибо за совет.
Помог только такой вариант:
1. В ЦБ выгрузить конфигурацию.
2. Снять ЦБ с поддержки.
3. В ЦБ "Загрузить конфигурацию из файла", тот же файл, сделанный в шаге 1. Добавить константу в конфигурацию.
4. Сделать выгрузку из ЦБ в УБ;
5. Загрузить в УБ. Применить обновление. Снова запустить в УБ обмен (выгрузить).
6. В ЦБ сделать обмен (загрузить) .
В 3 шаге добавил константу в конфигурацию ЦБ. Возможно, это излишне, но не пробовал иначе.
В УБ каждый день практически загружал конфигурацию - надоело до чертиков.
По поводу причины: уверен, что это динамическое обновление: в один день обновился динамически в ЦБ раза четыре, ошибка появилась в момент обновления конфигурации информационной базы в УБ. До этого обмен работал без сбоев.
Прекрасно помогла обработка, спасибо!
Метод 2 к большому сожалению также не помогает. Возникает исключение: "Искажены изменения конфигурации". Приведенный здесь пример касается весьма древних версий платформы 8.2, а может даже 8.1. На платформах 8.3.4 и выше фрагмент с хешами сейчас выглядит несколько иначе:
<v8de:Version>216.0</v8de:Version>
<v8de:Digest1>9302179fce9fe03be9b969e3f7a499f1</v8de:Digest1>
<v8de:Digest2 v2="46af761f437758f52340173bf43dceca">d114d6a71e1406c7de2e38
Отсюда видно, что версия метаданных, используемая сейчас, вдвое старше, чем в примере. Кроме того узел Digest2 выглядит также иначе. В настоящее время с учетом вышесказанного решение аналогичной проблемы у нас зашло в тупик. И поэтому мы склоняемся в третьему варианту. Это выгрузить через универсальный обмен данными из УБ то что нужно в ЦБ, а затем просто заново выгрузить образ периферийной базы и перезаписать её.
Снять с поддержки; Загрузить конфигурацию - загружаются даже закрытые модули.
После обновления вылезла ошибка "Конфигурация узла распределенной ИБ не соответствует ожидаемой"
Шаги из первого метода не помогли ,
Шаги из второго метода - тоже , удалял секции с изменениями конфигурации, менял уже Digest'ы как только мог, чистил кеш и т.д.
Решение которое помогло следующее:
1.выгружаем из ЦБ cf-файл;
2.отвязываем УБ от РИБ (метод УстановитьГлавныйУзел, готовую обработку можно найти в приложении или в других публикациях);
ВАЖНО ***
Перед заменой конфигурации в УБ сделал незначительные изменения (добавил примечание в первом попавшемся документе) , применил эти изменения, а затем уже следующие шаги.
3.заменяем конф. УБ на выгруженный в первом шаге cf-файл, для этого пользуемся меню "Загрузить конфигурацию из файла" (а не сравнением-объединением!!!);
восстанавливем признак РИБ для УБ.
После всего - обмен пошел
платформа --- 1С:Предприятие 8.3 (8.3.5.1248)
Шаги идут стандартно:
1. Отключить Главный Узел
2. Загрузить конфигурацию
Если на этом этапе сравнить конфигурации - они будут идентичными
3. Подслючить Главный Узел
Если на данном этапе сравнитьь конфигурации - они будут отличаться
PS. Удалось выяснить, что в 8.3.5.1248 нормальным образом не работает "Загрузить конфигурацию из файла..." в части создания новых объектов. Поэтому процедура видоизменяется примерно так. Точность не гарантирую, потому что воспроизвести не могу после исправления
1. Отключить главный узел
2. Сравнить, объединить с конфигурацией из файла... - создаются новые объекты из-за ошибки в Загразить концигурацию
3. Обновить конфигурацию базы данных
4. Загрузить конфигурацию из файла...
5. Обновить конфигурацию
6. Подключить главный узел
1.добавьте в в конфигураторе в ЦУ любой комент к любому документу
2.Запустите ЦУ в режиме предприятия с параметром ЗапуститьОбновлениеИнформационнойБазы
3.Сделайте обмен в ЦУ
4.Сделайте обмен в УБ
5.УБ запросит обновление базы,обновите
6.Сделайте контрольные обмены
Все ОК
То, о чём вы говорите - это первое, что пытаются сделать все, когда возникают проблемы с РИБ...
А в контексте данной статьи - это даже не первый, а "минуспервый" шаг, потому что нулевой - это чистка кэша (как недавно справедливо заметил коллега sergik_nsk).
Так что, коллега, поскромнее немного будьте, в этой жизни не всё так просто, как кажется на первый взгляд...
Просто написал что помогло мне,если Вас обидели слова "Да все проще" то я относил это к тому что если возникает ошибка "Конфигурация не соответствует ожидаемой" что бы не парится с остальными способами...
Как бы такого совета я тут не увидел и даже в коментах, где там он как минус первый указывается я тоже не нашел..
Дак вот все шаги я от и до прошел, не один не помог, помог только мой(с) способ,попутно очищая сбойную отправку Digest1 и Digest2 блоков из ЦУ в УБ в тот момент когда "Конфигурация не соответствует ожидаемой"..
Теперь про озвученный совет:
- добавить "любой комент к любому документу" - это значит просто инициировать обмен накопительных изменений метаданных между узлами РИБ;
- параметр "ЗапуститьОбновлениеИнформационнойБазы" вообще не относится к платформенным параметрам, а просто запускает в пользовательском режиме последовательность процедур обновления ИБ в пользовательском режиме из набора функций БСП, соответственно и исправить в обменных механизмах он ничего в принципе не может, и отработает только на конфигурациях, написанных под БСП.
Резюме: всё описанное не более чем "танцы с бубном", непонятно за счет чего приведшие к какому-то положительному результату. По такой же логике древние шаманы вызывали дождь.
У нас УТ 10 и перешли на 8.3.11 с 8.3.8, слетел обмен. Согрешил и динамически(делаю так всегда) сохранял наработки. Короче все к одному слетел обмен. Уверен на 99.9% из-за обновления платформы. пункты 1 и 2 не помогли, думаю как было сказано выше кем то, что новые платформы вносят какието свои изменения и причина в обновлении платформ. В общем зашел в ЦБ в документ поставил пробел в описания какогото поля(выгнал всех с базы). Сохранил, выгрузил из ЦБ и УРА!!! загрузил в УБ там F7. все заработало.
2.инициировать обмен накопительных изменений метаданных между узлами РИБ; - помойму это и надо сделать когда УБ не может принять сбойный Digest1 и Digest2 и ручное ковыряние файла обмена приводит к ошибке обмена "файл обмена был некорректно изменен", да и ковыряние скажем в 800 метровом файле не представляется возможным..
3.А всё остальное - и есть все остальное которые делает админ РИБ при возникновении проблем с обменами.
Резюме: помойму все выше описанное с самого начала и есть "танцы с бубном"
В стиле "ща я вас, салаги, тут всех жизни научу" ого это уже фантастика...
Перед кем мне еще надо извинится что бы Вы не выдумывали за меня мои выражения?
P/S Спасибо Вам за советы ,статья действительно очень познавательна! не в коем разе не хотел что либо очернить в выше описанном.
6. обязательно перезаписываем файл обмена из УБ (2-й пункт)! этот файл не должен быть загружен при обмене в ЦБ!
Т.е. до этого пункта все сработало и УБ приняло файл из ЦБ на который раньше ругалось, а вот теперь формирую файл в УБ и при его загрузке в ЦБ та ругается так же. А написано что файл "не должен быть загружен в ЦБ" - а какой файл в ЦБ тогда грузить чтобы она следующие файлы обмена корректно формировала?
В ЦБ должен попасть пакет обмена, получившийся после 5-го шага, т.к. именно он будет содержать квитирующий блок об идентичности версий конфигураций в УБ и в ЦБ.
Если версии платформ отличаются, то привести к той версии платформы, что и в центральном узле, либо версию выше чем в центральном узле.
Это касается новых релизов по бухгалтерии 3.0.44.155. также поправил обработку по включению, отключению узла.
И с учетом способа два все отлично сработало.
Хочу добавить: так не сработало на более поздних релизах УТ 11.1, пришлось сделать так - главный узел отключил, потом сразу загрузил cf, потом запустил конфу и разрешил восстановить главный узел, потом была ошибка отсутствия идентификаторов метаданных, сделал на главном узле для узла УБ в "составе отправляемых данных" -> "Зарегистрировать данные для восстановления подчиненного узла РИБ", после чего выгрузил из ЦБ, перезагрузил УБ и согласился с синхронизацией УБ, после синхронизации УБ продолжила обновление.
Платформа 1С:Предприятие 8.2 (8.2.17.153)
Конфигурация "Управление торговлей", редакция 10.3 (10.3.16.1)
Работаем через Хранилище.
В один момент, внесли изменения в печатную форму и модуль документа Перемещение товаров.
В базе имеются 7 РИБ узлов.
В 5-ть узлов обновления дошли прекрасно, конфигурация обновилась и обмен продолжил свою работу по расписанию.
А 2 узла начали писать, что ИБ не соответствует ожидаемой.
Первый способ не помог.
Второй тоже.
В других местах видел в статьях, люди писали, что нужно изменить объект, который последним был изменен. Якобы причина может быть в нем. Делал внесение левой константы, переименовывал печатные формы, правил код.
Не помогло.
На второй день, тупо сидел и повторял второй способ, пытаясь разобраться, что же узлу не нравится в файле выгрузки из ЦБ.
В конце концов, выгрузил в очередной раз свежий конфиг из ЦБ, и решил его не загружать, а запустить в режиме сравнения. Проверить, загрузился ли этот конфиг в прошлый раз и вот. Вижу есть расхождения.
Отменил - загрузил конфиг. Снова запустил в режиме сравнения. Вижу не помогло.
Ну фиг с ним с конфигом. Значит сделал сравнение - объединение.
Затем повторил процесс после окончания первого, снова сравнение. На этот раз вижу конфиги идентичны. Ура. Перезапустил конфигуратор и сделал просто загрузку конфига.
Привязал главный офис для обмена, запустил загрузку файла выгрузки из ЦБ. Файл заехал на отлично. Обмен был восстановлен между узлом и ЦБ.
Через пол часа кладовщики наткнулись на проблему, не открывается печать одного макета. Смотрю в конфигураторе. Макет есть. А вот функция к нему осталась старой. Выходит, восстановление обмена еще не есть гарантия восстановления работоспособности всей базы.
Пока появилась мысль внести изменения в функцию и снова растолкать обмен по узлам. Например написать в начале функции комментарий
// С этим доком я протрахался двое суток!
Ну и еще впереди такая же пляска с 7-мым узлом. Так что, буду отлаживать метод восстановления.
Раньше говорили - хочешь трахаться - купи мопед.
Сейчас и мопед не нужен, секса с 1с и так хватает.
Всем удачи, в сражении с ветряными мельницами.
Донкихот живет и процветает.
Столкнулся с описанной проблемой в нетиповой конфигурации. Выполнил обычные шаги по решению проблемы, но после загрузки конфигурации возникла ошибка при запуске предприятия с отсылкой к SQL таблице справочников (ругалось на одинаковые значения). Как оказалось, проблема решилась банальной остановкой служб SQL и 1С и их повторным запуском. Может быть кто-то сэкономит время и нервы :)
суть такая:
1. Обновление метаданных идёт через РИБ,
2. Обновление данных происходит через самописный обмен.
Ни разу не столкнулся с проблемой "восстановления узла", или т.н. "популярных" ошибок РИБ, Вы в слово то вдумайтесь!!! -ПОПУЛЯРНЫХ- ужас!!
в этом 2016 году я решил попробовать классическое РИБ (в файле xml содержатся и данные и метаданные) в большой надежде, что с 2010 года что-то изменилось.
УВЫ...буду переходить на вариант опробованный мною в 2014 году. о плюсах и минусах своего подхода могу рассказать, пишите в личку.
Насколько я понял, эта проблема возникает в следствие каких-либо нестандартных действий с РИБ, в частности как описано здесь.
Делаем вот что:
1. Выходим из всех конфигураторов и 1С.
2. Заходим в "C:\Users\%username%\AppData\Local\Temp".
3. Чистим всё: выделяем все файлы и папки, жмем на удаление. Что не удаляется - это не относится к 1С, пропускаем.
Возможно решение не всем подойдет, но мне помогло. У меня база файловая.
Для клиент-серверной базы может не пройти. Но думают там стоит чистить темп на сервере.
Методы 1 и 2 не помогали, версия платформы 8.3.6.
А проблема и решение оказались вот в чем:
1. Так получилось, что с ПБ не было обмена полгода, и чтобы восстановить обмен сделали новую ПБ, а старую ПБ сохранили на сервере 1с с названием +"_Old".
2. С новой ПБ обмен поработал пару дней, и начал выпадать в ошибки "Конфигурация узла распределенной ИБ не соответствует ожидаемой". Один раз помог первый способ, далее что то не пошло.
3. Не знаю, что именно решило проблему, но для начала были отключены регламентные задания в базе "_old", а затем эту базу совсем удалили из списка сервера 1С.
Короче, "танцы с бубном" и совсем непонятен корень проблемы...
Дык видимо в старой базе запускались задания обмена, а настройки были те же , что и в новой базе (а в новой вы наверняка обновили релиз).
При обмене с УБ на ЦБ передается точно такой же кусок который потом передает ЦБ на УБ, то есть одно и тоже.
первый идентификатор в строке <v8de:Digest2 v2=
Это не частный случай, а так всегда. не вводите людей в заблуждение
ну давайте разбираться на примере, а то многие верят людям на слово, чем я и сам порой страдаю
вот что содержится в файле из ЦБ
<v8de:Digest1>598efe639ab9508542946cc21468ab57</v8de:Digest1>
<v8de:Digest2 v2="fc9677a59f11dd6e87ca1db951fd57e1">45ff0d5842c51efb1b3378
вот что в файле из УБ до принятия последнего сообщения :
<v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
<v8de:Digest2 v2="0a7994e462a5ec5c03a24a3906bf9f00">c783f9d02cef02a523c66a
а вот что после :
<v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
<v8de:Digest2 v2="fe1079487016c66894596ea945f37241">b2c53f0a38604df4e16865
и пож-та покажите мне где тут одно и то же ?
или вы за кем то повторяете , не попробовав посмотреть самому ?
коллизия возникает из за того что что УБ не признает идентификатор ЦБ который она посылает в сообщении, нужно его подменить не меняя больше ничего, что бы новый прописался верно. И дальше все шло в автомате.
все делаем как описано до п 4.
делее
в файле выгруженном из УБ берем из строки
<v8de:Digest2 v2="e814f00fd7091bbccac3b5d8d3c523d7">2a37948939bf8b17fe152d
идентификатор 2a37948939bf8b17fe152dadc3d313b5
и вставляем его в файле выгруженном из ЦБ
в строке
<v8de:Digest2 v2="e814f00fd7091bbccac3b5d8d3c523d7">997a2385a205bdf5797473
вместо 997a2385a205bdf57974732496816e78
т.е. получаем строку <v8de:Digest2 v2="e814f00fd7091bbccac3b5d8d3c523d7">2a37948939bf8b17fe152d
и больше мы ничего не трогаем !
далее по инструкции 5-7.
Удачи всем.
до этого не принимало из за "несоответствия версий конфигураций",
( но естественно я перед этим загрузил актуальную конфигурацию в УБ).
После успешной первой загрузки из ЦБ сразу выгрузил обратно файл обмена из УБ и скормил ЦБ.
В итоге помогло вот что:
1. Выгружаем центральную базу и тупо загружаем её обратно, на выходе получаем значок изменения конфигурации, хотя в обычной ситуации его не должно быть
2. Ну а дальше 1й способ
Рекомендую дополнить описание первого метода - очистка кэша до операции с загрузкой CF
УРИБ - обычная звезда: центр и удаленные базы.
Один из узлов после изменения конфигурации и обновления узла перестал принимать пакеты из центра с сообщением, что "Конфигурация узла не соответствует ожидаемой".
Замена конфигурации в удаленном узле проблему не решила.
Изменение disgest в пакете из центра помогло загрузить пакет, но ответный пакет в центре был отвергнут.
В результате - в центре произведено изменение конфигурации, пакет с котором тоже отвергнут удаленным узлом с сообщением "Конфигурация узла не соответствует ожидаемой".
Помогла только чистка кэша метаданных - и пакеты стали приниматься и конфигурация получила новое изменение.
В моем случае после первого пункта УБ принимала файлы но ЦБ не принимала.
Я сделал все как во втором пункте но ситуация не поменялась.
Решение было следующим. В ЦБ добавляем константу, затем в УБ получаем файл обмена, применяем изменения и обмен восстанавливается.
"Ошибка SDBL: Ожидается имя таблицы (pos=25)"
помогло немного по другому:
1. выгружаем из УБ cf-файл, а не из ЦБ;
2. отвязываем УБ от РИБ;
3. заменяем конф. УБ на выгруженный в первом шаге cf-файл, для этого пользуемся меню "Загрузить конфигурацию из файла" (а не сравнением-объединением!!!);
4. восстанавливаем признак РИБ для УБ.
Помогло следующее.
1.Почистил кеш.
2. Установил платформу 8.3.10.2772.
3. Выгрузил/загрузил DT.
4. Выполнил действия по способу 1 данной статьи (отвязал ГУ, загрузил CF, привязал ГУ обратно).
Все заработало.
Подозреваю, в платформе 8.3.12.1529 косяк есть какой-то.
1. Загружаем cf из центра в точку.
2. Правим файл из цб:
2.1. Блок config меняем на аналогичный из ПБ.
2.2. Убираем тэги v2 и Extensions из Digest2. Получается примерно так
<v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">
<v8de:Version>216.0</v8de:Version>
<v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
<v8de:Digest2>d41d8cd98f00b204e9800998ecf8427e</v8de:Digest2>
</v8de:Config>
После этого файл загружается в ПБ и дальше все работает.
Базы УТ 10, 2 штуки разных версий. Одна взлетела после замены конфигурации в периферийной, а одна ругается что конфигурация не соответствует. При чем, создаю образ, настраиваю обмен тут же меняюсь и сразу не соответствует.
Перед переходом на 8.3 тестировал. Вроде ОК.
Что еще можно сделать чтобы обмен заработал?
Попробуйте выгрузить cf из центра, создать новую базу, загрузить туда cf, снова выгрузить cf из новой базы и вот последний выгруженный cf загрузить обратно в центральную и периферийные базы.
Есть подозрение, что у 8.3.12.1595 криво рассчитывается хэш метаданных конфигураций. Мне помогла вот такое выравнивание конфигураций через третью пустую базу. Конфигурация тоже, кстати, УТ 10.3 была
1. Создаем обязательно архивную копию базы с помощью выгрузки или копированием файла 1Cv8.cd. Данная процедура должна войти в привычку у профессионального программиста.
2. Открываем конфигуратор центрального узла и сохраняем конфигурацию в файл («Конфигурация — Сохранить конфигурацию в файл»). сохраненный cf файл любыми способами доставляем к подчиненному узлу, где возникла ошибка.
3. Заранее подготавливаем обработку со следующим тексом
Процедура КнопкаВыполнитьНажатие(Кнопка)
Если ПланыОбмена.ГлавныйУзел()<> Неопределено Тогда
СохранитьЗначение(«ВосстановитьЗначениеГлавногоУзлаВПодчиненном», ПланыОбмена.ГлавныйУзел());
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
КонецЕсли;
Предупреждение(«Главный узел отключен»);
КонецПроцедуры
Процедура ОсновныеДействияФормыВключитьОбратно(Кнопка)
Если ПланыОбмена.ГлавныйУзел()= Неопределено Тогда
ПланыОбмена.УстановитьГлавныйУзел(ВосстановитьЗначение(«ВосстановитьЗначениеГлавногоУзлаВПодчиненном»));
КонецЕсли;
Предупреждение(«Главный узел восстановлен»);
КонецПроцедуры
4. Открываем в режиме «Предприятия» и используем ее.
5. Открываем конфигуратор подчиненного узла и если конфигурация находится на поддержке, то снимаем ее (Конфигурация — Поддержка — Настройки поддержки — Снять с поддержки). Если нет, то пропускаем данный пункт.
6. Загружаем наш cf файл который был сохранен в центральном узле в текущую конфигурацию(«Конфигурация — Загрузить конфигурацию из файла…») и применяем обновление.
7. Возвращаемся в режим предприятия и применяем снова обработку, только теперь включаем обратно. Запускаем обмен и все будет работать!
На подчиненном узле тоже почистил кеш, отвязал от Главного узла, загрузил cf от ЦБ, восстановил узел. запустил обмен, ошибка сохранилась.... ума не приложу что еще сделать...
На подчиненном узле тоже почистил кеш, отвязал от Главного узла, загрузил cf от ЦБ, восстановил узел. запустил обмен, ошибка сохранилась.... ума не приложу что еще сделать...
Digest2 в цб совпадает с Digest2 из УБ
...как она может не соответствовать ожидаемой (по мнению платформы), если конфу загружал прям из цб..
Платформа 8.3.12.1529,
конфигурация УТ10.3
(ошибка произошла после обновления Платформы)
У меня была Розница 2.2.11, РИБ по магазинам. Выгрузка cf из центра и последующая загрузка в УБ не помогла. Блок <config> во входящем и исходящем файле были одинаковы. Но все равно "конфигурация не соответствует"
Решил так - взял блок <config> из файла обмена с другим узлом РИБ, с которым все хорошо. Файл обмена с таким блоком загрузился в проблемную УБ, и выгруженный файл уже был с этим блоком. Все заработало.
Когда же 1С наконец-то станет стабильным, а не модным продуктом....
2-ОЙ МЕТОД работает! уже не первый раз спасает
даже после ошибок: Возникает исключение: "Искажены изменения конфигурации".
так же есть нюанс
вот пример из ЦБ
-<v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">
<v8de:Version>216.0</v8de:Version>
<v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
<v8de:Digest2 Extensions="0000000000000000000000000000000000000000" v2="39115c7435bbe0e714fe316dba19a5a2">d41d8cd98f00b204e98009
</v8de:Config>
сделал так
-<v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">
<v8de:Version>216.0</v8de:Version>
<v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
<v8de:Digest2>d41d8cd98f00b204e9800998ecf8427e</v8de:Digest2>
</v8de:Config>
т.е. Extensions="0000000000000000000000000000000000000000" v2="39115c7435bbe0e714fe316dba19a5a2 убрать и сделать как в пункте 2!
Словил эту ошибку и не помогла ни очистка кэшей, ни изменение/обновление конфигураций, ни снятие с поддержки, ни выгрузка-загрузка конфигураций ЦБ > УБ , УБ > ЦБ, не помогла подмена хешей в файлах обмена, ни комбинация последних 2 методов. А вот сверка версий платформы на узлах навела на правильный ответ.
Конкретно в моем случае - обновили молча Бухгалтерию 3.0, вместе с ней пришла платформа 8.3.14. ЦБ УТ11.4 до этого работала на платформе 8.3.13, и в УБ продолжали использовать 8.3.13. А ошибка называлась "Конфигурация узла распределенной ИБ не соответствует ожидаемой"...
Этот случий если 1 вариант не получился, а 2 очень сложно. Выход. Выручает меня не один раз!!!
1)Добавляет какой-то новое поле. Я добавил константу..
2)Обновляем конфигурацию у главного узлаэ.
3)передаем ее по рибу.
4)грузим обмен на филиале.
5)получаем обновление и радуемся.
6)обновляем филиал.
РИБ восстановлен
Для меня это не совсем понятно, что именно имеется ввиду, но лично я вижу 2 варианта:
Вариант 1: Конфигурация\Сохранить конфигурацию в файл.
Вариант 2: Конфигурация\Поставка конфигурации\Создать файлы поставки и обновления конфигурации.
Итоговый вариант очень сильно зависит от того, какой из вариантов использовать.
Прочитал статью и отзывы (удачные и не удачные), продолжаю дальше танцевать с бубном, чтобы восстановить обмен. Большую часть из рекомендаций использовал - пока безрезультатно. Приходится уже подумывать о варианте загрузки из УБ в ЦБ с помощью xml, и создания нового образа РИБ. И это недоразумение между вариантами выгрузки cf-файла добавляет в 2 раза больших танцев с бубном.
sashapere, в конфигураторе Администрирование\Тестирование и исправление.
ВЫХОД:
Создаете через конвертацию обмен данных. Помещяете в ЦБ и УБ обмен идентичный с планом обмена (можно даже РИБ не отвязывать...но при следующих изменениях в конфигуратор - можно отвязать навсегда) и обмен работает в полном объеме.
Малость изменения конфигурации нужно копировать из ЦБ в УБ .
Это временно решение, но рабочее и без создания нового РИБа по УБ!
Добавлю ПОСЛЕ НЕДЕЛИ использования РИБа ошибка ушла.
т.е. я работал обычным обменом и решил внести изменения в конфигурацию. Выгрузил и УБ принял изменения и соответсвенно из УБ в ЦБ принял так же.
Вывод:
Выше указанные методы 1 и 2 не помогли. Обмен встал. РИБ стал не рабочий.
Вылечил простой обмен))
- Выгрузил конфигурацию из ЦБ;
- Отключился от хранилища;
- Создал в одном документе реквизит для структурных изменений;
- Снял конфигурацию с поддержки;
- Загрузил выгруженную на первом шаге конфигурацию, после чего она снова встала на поддержку и по F7 обновил конфигурацию БД;
- Сделал выгрузку пакета из ЦБ;
- Сделал в ПБ загрузку этого пакета (к этому времени размер пакета составлял больше 1Гб). Загрузка поработала минуту и прекратилась с ошибкой; в журнале регистрации посмотрел, что хочет загрузить изменения конфигурации в базу.
- В ПБ зашел в Конфигуратор и по F7 обновил конфигурацию БД;
- Запустил ПБ после обновления конфигурации БД, стартовое окно висело где-то полчаса, я понял что продолжилась загрузка пакета обмена;
- Сделал выгрузку пакета из ПБ;
- Сделал загрузку этого пакета в ЦБ, пакет прошел без ошибок.
Все!
1. выгрузил конфигурацию ЦБ в файл.
2. выгрузил конфигурацию УБ в файл.
3. Загрузил конфигурацию УБ в ЦБ. Запустил обмен. Обмен прошел.
4. Загрузил в ЦБ конфигурацию из пункта 1. Запустил обмен
На сколько это утверждение актуально для свежих релизов? Я таким образом отвязал узел (добавил команду к запуску конфигуратора), и исправил по способу 1. После зашел в удаленный узел, он предложил восстановить РИБ, согласился и всё прошло.
После некоторых манипуляций загрузка в узле шла при способе 2, но в ЦБ данные не загружались.
Как оказалось, база была бита не один раз, возможно в этом причина, что оба способа у меня не работали.
После многих попыток компиляций способов из поста и комментариев нашел рабочую для меня последовательность действий.
Некоторые действия возможно были лишними, но на это нужно время, чтобы проверить, и убрать лишнее.
Моя рабочая последовательность действий лечения данной ошибки:
- Бэкап.
- Тестирование базы (здесь и далее chdbfl.exe). Была ошибка "Повреждены данные таблицы '_SYSTEMSETTINGS'. Восстановлено 202132 из 202133 записей.. Потеряно 1 значений полей неограниченной длины".
- В конфигураторе добавить новую константу, удалить ее, обновить конфигурацию.
- Реструктуризация. Ошибка "Ошибка СУБД:", и далее либо "Ошибка SQL: Поле не найдено 'Email'", либо "Файл базы данных поврежден". У меня на копии была 1-я ошибка, у клиента 2-я.
- Тестирование базы - ошибок не обнаружено.
- Реструктуризация. Ошибок нет.
- Тестирование базы. Для уменьшения размера файла БД. База с 6 Гб увеличилась до 12 Гб.
- Сохранить конфигурацию в файл.
- Бэкап на всякий случай, чтобы заново не проходить шаги, если что-то не получится. Опционально.
- Снять с поддержки.
- Загрузить только что сохраненную конфигурацию (не сравнить/объединить, а именно загрузить). Конфигурация обратно поставится на поддержку. F7.
- Синхронизация в ЦБ - выгружаем данные.
- Синхронизация в узле - все ОК.
- Синхронизация в ЦБ - все ОК.
Рейтинг: 1425
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 65456
Создание 09.02.10 02:17
Обновление 09.02.10 00:00
Просмотры 243556
Загрузки 6926
Рейтинг
428
Комментарии 195
Код открыт Не указано
Рубрики Корректировка данных Перенос данных 1C
Кому
Системный администратор
,
Разработчик
Тип файла Внешняя обработка (ert,epf)
Платформа 1С:Предприятие 8
Конфигурация 1C:Бухгалтерия
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
