Популярные ошибки РИБ и способы их исправления. Часть 1. Конфигурация узла распределенной ИБ не соответствует ожидаемой
Конфигурация узла распределенной ИБ не соответствует ожидаемой. Одна из самых популярных ошибок РИБ. Приведены стандартная методика устранения (уже публиковалась ранее) и расширенная (для сложных случаев).
Комментарии
Избранное
Подписка
Сортировка:
Древо
(4)
всё возможно, но для этого нужно знать алгоритм вычисления :) а Version - та что хранится в конфигурации ?
её можно для этого можно использовать различные инструменты например EI, или доработать мою обработку, которая сохраняет cf из бд.
Elisy пишет:
А можно ли программно из 1С получить хэши (Digest1 и Digest2) и версию (Version)? Или это информация для внутреннего использования в 1С?
А можно ли программно из 1С получить хэши (Digest1 и Digest2) и версию (Version)? Или это информация для внутреннего использования в 1С?
всё возможно, но для этого нужно знать алгоритм вычисления :) а Version - та что хранится в конфигурации ?
её можно для этого можно использовать различные инструменты например EI, или доработать мою обработку, которая сохраняет cf из бд.
(6) да, к своему великому сожалению наткнулся на эту ветку уже после описанных в статье событий... хотя в то время перелопатил в поиске решения почти всю "партнёрку"... сэкономил бы часов 6 своего рабочего времени... :(
там, правда, Андрей предлагает удалять/восстанавливать узел (на мой взгляд, чтобы сбросить регистрацию проще воспользоваться обработкой "РегистрацияИзмененийДляОбмена"), что в моём случае было совершенно неприемлемо (все изменения должны были дойти до своих адресатов)...
там, правда, Андрей предлагает удалять/восстанавливать узел (на мой взгляд, чтобы сбросить регистрацию проще воспользоваться обработкой "РегистрацияИзмененийДляОбмена"), что в моём случае было совершенно неприемлемо (все изменения должны были дойти до своих адресатов)...
(10) нет, не совсем понятно про "далее все понятно"... можно поподробнее, что дает копирование изменений в "некий резервный узел"? а дальше-то что? перевыгружать узлы и добивать их зарегистрированными изменениями? а если каждый узел "весит" 4-5Гб или больше? а узлов 20-30 штук?
(11) у меня под рукой доступа на партнерский форум нет в чем там суть я могу только догадываться. но я отреагировал на вашу фразу
>>что в моём случае было совершенно неприемлемо (все изменения должны были дойти до своих адресатов)...
для того что бы не потерять регистрацию в случаи неких манипуляций с узлом достаточно создать еще один узел как хранилище изменений - перелить из нужного узла регистрацию изменений. далее сделать все с ним что нужно и перелить регистрацию обратно.
если узлов много можно процесс автоматизировать.
>>что в моём случае было совершенно неприемлемо (все изменения должны были дойти до своих адресатов)...
для того что бы не потерять регистрацию в случаи неких манипуляций с узлом достаточно создать еще один узел как хранилище изменений - перелить из нужного узла регистрацию изменений. далее сделать все с ним что нужно и перелить регистрацию обратно.
если узлов много можно процесс автоматизировать.
(12) суть понял... там другой случай... в партнерской ветке Андрей Чичерин предлагал на первых шагах:
суть - очистить таблицу регистрации изменений... для чего это нужно - для меня так и осталось загадкой (потом же хлопот не оберешься чтобы синхронизировать узлы), а в своем комменте я просто предложил более простой вариант проведения этой операции...
1. в центральной ИБ удалить узел плана обмена, соответствующий удаленному узлу (при этом все записи о регистрации изменений для удаленного узла будут потеряны);
2. в центральной ИБ создать новый узел плана обмена, соответствующий удаленному узлу (код узла должен соответствовать удаленному на первом шаге);
2. в центральной ИБ создать новый узел плана обмена, соответствующий удаленному узлу (код узла должен соответствовать удаленному на первом шаге);
суть - очистить таблицу регистрации изменений... для чего это нужно - для меня так и осталось загадкой (потом же хлопот не оберешься чтобы синхронизировать узлы), а в своем комменте я просто предложил более простой вариант проведения этой операции...
Попробовал запустить обработку для установки главного узла.
Получил:
Что делаю не так?
Получил:
{Форма.Форма.Форма(6)}: Ошибка при вызове метода контекста (УстановитьГлавныйУзел): Недопустимое значение параметра (параметр номер '1')
ПланыОбмена.УстановитьГлавныйУзел(ГлавныйУзел);
по причине:
Недопустимое значение параметра (параметр номер '1')
ПланыОбмена.УстановитьГлавныйУзел(ГлавныйУзел);
по причине:
Недопустимое значение параметра (параметр номер '1')
Что делаю не так?
(26) Есть решение:
- Главный узел ищут в УФ так:
Если хотите снять главный узел, то используйте ПланыОбмена.УстановитьГлавныйУзел(Неопределено)
Если установить - то, например, так ПланыОбмена.УстановитьГлавныйУзел(ПланыОбмена.ИмяВашегоОбмена.НайтиПоКоду("КД"));
. Учтите, что сюда можно ставить узлы только из тех планов, у которых в свойствах стоит галочка "Распределенная"
ХМ.. работает только для старых версий Розницы
- Главный узел ищут в УФ так:
Если хотите снять главный узел, то используйте ПланыОбмена.УстановитьГлавныйУзел(Неопределено)
Если установить - то, например, так ПланыОбмена.УстановитьГлавныйУзел(ПланыОбмена.ИмяВашегоОбмена.НайтиПоКоду("КД"));
. Учтите, что сюда можно ставить узлы только из тех планов, у которых в свойствах стоит галочка "Распределенная"
ХМ.. работает только для старых версий Розницы
(14) Использование хранилища - нет не может... Хранилище - тупой (но очень полезный) инструмент для синхронизации действий при групповой разработке...
А вот хаотичные динамические обновления из-за несогласованного регламента применения изменений на рабочей базе вполне могут быть такой причиной. Особенно если узлов много, а вы не следите за тем, что подтверждения о принятии изменений с узлов доходят до центральной БД.
Устанавливайте жёсткий регламент наката изменений на рабочую базу, и по возможности включайте в настройках узлов галочку "Выгружать только при успешной загрузке".
А вот хаотичные динамические обновления из-за несогласованного регламента применения изменений на рабочей базе вполне могут быть такой причиной. Особенно если узлов много, а вы не следите за тем, что подтверждения о принятии изменений с узлов доходят до центральной БД.
Устанавливайте жёсткий регламент наката изменений на рабочую базу, и по возможности включайте в настройках узлов галочку "Выгружать только при успешной загрузке".
(17)
Вот у меня тоже абсолютно уникальная ситуация, один узел УБ работает нормально, создал еще один, и при первом же обмене пишет такую чушь. Все проведенные действия спасали только на один раз загрузить в УБ и все потом опять по новой. Заного создаю образ, загружаю конфу, вообще ничего не помогает, пишет о несоответствии и в Уб и в ЦБ...
Вот у меня тоже абсолютно уникальная ситуация, один узел УБ работает нормально, создал еще один, и при первом же обмене пишет такую чушь. Все проведенные действия спасали только на один раз загрузить в УБ и все потом опять по новой. Заного создаю образ, загружаю конфу, вообще ничего не помогает, пишет о несоответствии и в Уб и в ЦБ...
(16) сегодня такое было, первый способ знал и сразу его попорбовал, непомогло, второй способ тоже сделал помогло точно также на один обмен хватило. Вечером уже руки опустились, "звонок другу" помог:) Суть: изменить конфу главного узла и сделать обмен, в дочерний узел просто примет изменения от главного, обновляем дочерний. Все просто и тупо и сработало, я в шоке.
Блин...все мозги мне это несоответствие проело! Один раз месяц назад мне первый способ помог. Теперьуже руки опускаются...Второй способ не могу пименить т.к. после проделывания пунктов 1-4 1С просто тупо вываливается с руганью на basic.dll
Уже пробовал в ЦБ выгрузить начальный образ для этого узла, перенес, при первом же обмене опяь ошибка не соответствие ожидаемой!
Что делать????!!!!
Уже пробовал в ЦБ выгрузить начальный образ для этого узла, перенес, при первом же обмене опяь ошибка не соответствие ожидаемой!
Что делать????!!!!
Ну первый метод очень много где описывается, а вот можете второй пояснить.. приемом из ЦБ сообщения с его хещем - меняет хеш УБ? И тем самым синхронизирует единственный параметр, присутствующий в обоих сообщениях, так?и после того обмен(по идее) опять идет "как по маслу"?
Отдельное спасибо NewNick, интересный способ насчет узла с копированием регистрации изменений.
Отдельное спасибо NewNick, интересный способ насчет узла с копированием регистрации изменений.
Включение метода УстановитьГлавныйУзел в Попытку приводит к тому что не выводятся описания ошибок. Например когда в распределенной базе присутствуют дополнительные сеансы. Правильно определить ошибку установки главного узла смог только после закомментирования строк попытки. Вот такие грабли :).
Похоже, я единственный, у кого первый метод не сработал :)
В конфигураторе пункт меню "Загрузить конфигурацию из файла" неактивен, хотя конфигурация открыта. Как убедиться, что метод УстановитьГлавныйУзел сработал? Может в этом дело?
В конфигураторе пункт меню "Загрузить конфигурацию из файла" неактивен, хотя конфигурация открыта. Как убедиться, что метод УстановитьГлавныйУзел сработал? Может в этом дело?
А база скульная или файловая? У нас SQL. Первым способом всегда пользовался и всегда помогало на 8.1. А вот случилось на 8.2 и ни в какую. Второй способ только первый раз помог. Причем он как-то странно помог. Был обмен в фоновом режиме на серваке настроен, так он при обмене продолжал нам сообщать что "Конфигурация узла распределенной ИБ не соответствует ожидаемой". А вот локально делаешь обмен и все проходит. Сначала подумали на проблемы с серваком и его нужно переставлять. Первым делом перезагрузили и 1с-сервер и сервер-SQL - не помогает. Сделали переферийной базе выгрузку-загрузку данных и в копии обмен спокойно прошел(!). Ну взяли приатачили в скуле эту базу на старый адрес и обмен снова не работает!?! И вот здесь уже понял, что нужно просто переподключить базу в 1с-сервере!!! И все спокойно заработало, как буд-то ничего не было. Конечно у пользователей после этого почистили в "Documents and Settings" весь мусор в папке "1С". Так что, если скульная базка попробуйте сначала просто переподключить базу в 1с-сервере.
(39) PONOM, совершенно верно, хэш конфигурации сохраняется еще и в кэше приложения. Если система ориентируется на этот "мусор", то даже после создания нового узла и загрузки его через .dt в старую базу, проблема сохранится. И дайджесты конфигурации из УБ в ЦБ будут выгружаться те же, что привели к появлению ошибки о несоответствии конфигураций:) Поэтому не лишним будет первым делом почистить кэш в подобной ситуации, может сэкономить уйму времени. Думаю, очень многие сталкивались, например, с рассинхроном основной конфигурации с конфигурацией поставщика, которая также лечилась очисткой кэша приложения.
Честно говоря не понимаю проблемы в данной теме. Да когда конфа обновляется в главной базе,то в подчиненную передаются данные о изменении и главная видит , что конфа подчиненная не обновилась, поэтому и пишет Конфигурация узла распределенной ИБ не соответствует ожидаемой. Хорошо загружать ,выгружать если 1 подчиненная , а если их 10, то целый день только и сидеть перезагружать конфигурации. По моему тут 2 способа. 1 способ писать батник, который должен периодически обновлять конфу на переферии. 2 способ когда конфа в перефирии вываливается с ошибкой чтения мы используем команду ПрекратитьРаботуСистемы(Истина, " CONFIG /UpdateDBCfg ");
Все конфигурация сама обновляется.
У меня , например, запуск 1с стоит на расписание под событием обмен при запуске под определенным пользователем.
В главной конфа обновилась. На перефирии конфа вывалилась, но перед этим обновилась и далее конфа уже запустилась обновленная.
Все конфигурация сама обновляется.
У меня , например, запуск 1с стоит на расписание под событием обмен при запуске под определенным пользователем.
В главной конфа обновилась. На перефирии конфа вывалилась, но перед этим обновилась и далее конфа уже запустилась обновленная.
Была такая же проблема. С ходу по инструкции Первой и Второй не получилось, на втором обмене опять ничего не грузится. Решили так: внесли в центральную базу еще изменение (константу добавили) - и дальше по инструкции с подменой Digest1 и Digest2. Вуаля! Базы подвязались, обмен пошёл!
Спасибо автору за его методу. Хотелось бы поделиться своим опытом.
Сперва позволю себе процитировать вот эти строки автора статьи:
Смею заверить, автор ошибается. Лично на своей шкуре обжигался этой хренью (динамическим обновлением).
Зарекался..... Но, очередной аврал и ... согрешил.
Итог: при очередном обновлении все нижестоящие узлы стали раком.
РЕШЕНИЕ: Испробовал метод №1 - ранее помогал безотказно - НЕ помогло!
Долго танцевал с бубном примеряя на себя метод №2 - результат не утешителен: нижестоящие базы стали кушать входящие данные, а вот Центральный узел - обратно обмены не принимал.
МОЕ РЕШЕНИЕ:
1. Снял ЦБ с поддержки.
2. Взял cf-ник ЦБ, который был "до динамического обновления". Загрузил его в конфигурацию ЦБ.
Обновил конфигурацию БД ЦБ
3 Произвел выгрузку из ЦБ
4. Произвел повторную загрузку в Распределенный узел. (прошел на ура!!!)
5. Далее.... .все пошло по накатанной.
6. Все действия 1-4 повторил для остальных узлов.
ps: данному методу не помешали даже предыдущие танцы со способом №1 и №2.
Сперва позволю себе процитировать вот эти строки автора статьи:
Есть также мнение, что к этой ошибке приводит использование механизма динамического обновления базы. Здесь есть сомнения, потому как с одной стороны динамическое обновление никогда не затрагивает структуры БД, а механизмы РИБ всё-таки работают именно со структурой БД, а не с прикладной её частью
Смею заверить, автор ошибается. Лично на своей шкуре обжигался этой хренью (динамическим обновлением).
Зарекался..... Но, очередной аврал и ... согрешил.
Итог: при очередном обновлении все нижестоящие узлы стали раком.
РЕШЕНИЕ: Испробовал метод №1 - ранее помогал безотказно - НЕ помогло!
Долго танцевал с бубном примеряя на себя метод №2 - результат не утешителен: нижестоящие базы стали кушать входящие данные, а вот Центральный узел - обратно обмены не принимал.
МОЕ РЕШЕНИЕ:
1. Снял ЦБ с поддержки.
2. Взял cf-ник ЦБ, который был "до динамического обновления". Загрузил его в конфигурацию ЦБ.
Обновил конфигурацию БД ЦБ
3 Произвел выгрузку из ЦБ
4. Произвел повторную загрузку в Распределенный узел. (прошел на ура!!!)
5. Далее.... .все пошло по накатанной.
6. Все действия 1-4 повторил для остальных узлов.
ps: данному методу не помешали даже предыдущие танцы со способом №1 и №2.
Ну если совсем ничего не помогает, тогда следующий вариант, не менее геморройный, но 100% рабочий.
1. Создаем новую базу идентичного релиза.
2. Переносим в него СРАВНЕНИЕМ И ОБЪЕДИНЕНИЕМ доработки из ЦБ.
3. переносим с помощью Универсальной выгрузкой загрузкой XML все данные.
4. Старую базу в архив. Работаем в новой. Узлы создаем заново.
К этому я пришел после того, как испробовал все варианты, описанные здесь и в других источниках.
P.S. Изначально ЦБ крутилась на PostgreSQL. Обмен естественно не выполнялся. И даже работа в файловом варианте позже не давала положительный результат.
Всем удачи!
1. Создаем новую базу идентичного релиза.
2. Переносим в него СРАВНЕНИЕМ И ОБЪЕДИНЕНИЕМ доработки из ЦБ.
3. переносим с помощью Универсальной выгрузкой загрузкой XML все данные.
4. Старую базу в архив. Работаем в новой. Узлы создаем заново.
К этому я пришел после того, как испробовал все варианты, описанные здесь и в других источниках.
P.S. Изначально ЦБ крутилась на PostgreSQL. Обмен естественно не выполнялся. И даже работа в файловом варианте позже не давала положительный результат.
Всем удачи!
Понятно как решать проблему. А вот из-за чего она случается не очень понятно... У меня такая ситуация возникла после обновления конфигурации БП ред. 2.0.47.7 (типовая, на поддержке). Причем пробовал обновлять и через конфигуратор, и через 1сПредприятие, в пользовательском режиме. Написал в 1с - жду ответа...
(50) grap, вот кстати и официальный ответ от 1с подошел:
Ваше обращение зарегистрировано под номером SW782187 / 3. Пожалуйста, в тексте следующих обращений на эту же тему ссылайтесь на этот номер.
Это ошибка платформы. По предварительным данным исправлена в версии 8.2.18.108.
Это ошибка платформы. По предварительным данным исправлена в версии 8.2.18.108.
50.grap
Понятно как решать проблему. А вот из-за чего она случается не очень понятно... У меня такая ситуация возникла после обновления конфигурации БП ред. 2.0.47.7 (типовая, на поддержке). Причем пробовал обновлять и через конфигуратор, и через 1сПредприятие, в пользовательском режиме. Написал в 1с - жду ответа...
Добрый день! У нас та же проблема с ред.2.0.47.7 -причем у нас несколько разных юр.лиц с РИБами -и везде обмен перестает работать после обновления ЦБ на 2.0.48.9. Мы-простые ,скромные пользователи :))) и никак не можем решить эту задачку. Помогите, пожалуйста, по-шагово!!!
2 метод не помог, из УБ в ЦБ упорно не выгружалось.
3 метод.
1.В ЦБ выгрузить конфигурацию.
2.Снять ЦБ с поддержки.
3.В ЦБ "Загрузить конфигурацию из файла", (только что выгруженную.)
ну а дальше по 2 методу.
Только таким способом все заработало.
3 метод.
1.В ЦБ выгрузить конфигурацию.
2.Снять ЦБ с поддержки.
3.В ЦБ "Загрузить конфигурацию из файла", (только что выгруженную.)
ну а дальше по 2 методу.
Только таким способом все заработало.
(55) dovolsky, способ рабочий.
Немного присмотревшись понял, что при снятии конфы с поддержки и проведения выгрузки информации, то тот кусок кода, который необходимо менять во втором пункте самостоятельно обнуляется. Т.е. регистрация изменения конфигурации к конфигурации поставщика сбрасывается.
Немного присмотревшись понял, что при снятии конфы с поддержки и проведения выгрузки информации, то тот кусок кода, который необходимо менять во втором пункте самостоятельно обнуляется. Т.е. регистрация изменения конфигурации к конфигурации поставщика сбрасывается.
(55) dovolsky,
Спасибо за совет.
Помог только такой вариант:
1. В ЦБ выгрузить конфигурацию.
2. Снять ЦБ с поддержки.
3. В ЦБ "Загрузить конфигурацию из файла", тот же файл, сделанный в шаге 1. Добавить константу в конфигурацию.
4. Сделать выгрузку из ЦБ в УБ;
5. Загрузить в УБ. Применить обновление. Снова запустить в УБ обмен (выгрузить).
6. В ЦБ сделать обмен (загрузить) .
В 3 шаге добавил константу в конфигурацию ЦБ. Возможно, это излишне, но не пробовал иначе.
Спасибо за совет.
Помог только такой вариант:
1. В ЦБ выгрузить конфигурацию.
2. Снять ЦБ с поддержки.
3. В ЦБ "Загрузить конфигурацию из файла", тот же файл, сделанный в шаге 1. Добавить константу в конфигурацию.
4. Сделать выгрузку из ЦБ в УБ;
5. Загрузить в УБ. Применить обновление. Снова запустить в УБ обмен (выгрузить).
6. В ЦБ сделать обмен (загрузить) .
В 3 шаге добавил константу в конфигурацию ЦБ. Возможно, это излишне, но не пробовал иначе.
(55) dovolsky, сейчас помог только ваш вариант.
В УБ каждый день практически загружал конфигурацию - надоело до чертиков.
По поводу причины: уверен, что это динамическое обновление: в один день обновился динамически в ЦБ раза четыре, ошибка появилась в момент обновления конфигурации информационной базы в УБ. До этого обмен работал без сбоев.
В УБ каждый день практически загружал конфигурацию - надоело до чертиков.
По поводу причины: уверен, что это динамическое обновление: в один день обновился динамически в ЦБ раза четыре, ошибка появилась в момент обновления конфигурации информационной базы в УБ. До этого обмен работал без сбоев.
А у меня был такой случай, сделал первый метод, не помогло, потом заметил, обмен по расписанию выполняется, а интерактивно нет - выдает "Конфигурация не соответствует ожидаемой". Проверил настройки обмена - в УБ не стояла галка интерактивного обмена "Выполнять под полными правами". Хорошо что не стал сразу делать второй способ )
Пишу сюда, так как это самая часто встречающаяся ссылка по данной ошибке. Мне не помогли те действия, что были описаны в 1 и 2 вариантах, не помогли и действия описанные на просторах интернета. Пробовал вариант с тестированием базы, очисткой кеша, перезагрузки в периферийную конфигурации базы данных. Даже после создания новой распределенной базы ошибка оставалась и в вновь созданную базу обмен не проходил, ошибка оставалась "Конфигурация узла распределенной ИБ не соответствует ожидаемой". Поэтому еще один вариант, который мне после трех дней изысканий все-таки помог, это простое снятие конфигурации с поддержки в главной базе. После этого прошел обмен и периферийная база запросила обновить конфигурацию. Может кому описанный мной способ поможет, так как по моей ситуации я решений в интернете не нашел.
Метод 1 не подходит для специализированных конфигураций, т.к. в них присутствуют закрытые общие модули, которые нельзя снять с поддержки, а значит загрузить внешнюю конфигурацию из файла не получится.
Метод 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 выглядит также иначе. В настоящее время с учетом вышесказанного решение аналогичной проблемы у нас зашло в тупик. И поэтому мы склоняемся в третьему варианту. Это выгрузить через универсальный обмен данными из УБ то что нужно в ЦБ, а затем просто заново выгрузить образ периферийной базы и перезаписать её.
Метод 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 выглядит также иначе. В настоящее время с учетом вышесказанного решение аналогичной проблемы у нас зашло в тупик. И поэтому мы склоняемся в третьему варианту. Это выгрузить через универсальный обмен данными из УБ то что нужно в ЦБ, а затем просто заново выгрузить образ периферийной базы и перезаписать её.
У меня РИБ : ЦУ на сервере , узлы файловые (20 шт), 1С 8.2.18.102
После обновления вылезла ошибка "Конфигурация узла распределенной ИБ не соответствует ожидаемой"
Шаги из первого метода не помогли ,
Шаги из второго метода - тоже , удалял секции с изменениями конфигурации, менял уже Digest'ы как только мог, чистил кеш и т.д.
Решение которое помогло следующее:
1.выгружаем из ЦБ cf-файл;
2.отвязываем УБ от РИБ (метод УстановитьГлавныйУзел, готовую обработку можно найти в приложении или в других публикациях);
ВАЖНО ***
Перед заменой конфигурации в УБ сделал незначительные изменения (добавил примечание в первом попавшемся документе) , применил эти изменения, а затем уже следующие шаги.
3.заменяем конф. УБ на выгруженный в первом шаге cf-файл, для этого пользуемся меню "Загрузить конфигурацию из файла" (а не сравнением-объединением!!!);
восстанавливем признак РИБ для УБ.
После всего - обмен пошел
После обновления вылезла ошибка "Конфигурация узла распределенной ИБ не соответствует ожидаемой"
Шаги из первого метода не помогли ,
Шаги из второго метода - тоже , удалял секции с изменениями конфигурации, менял уже Digest'ы как только мог, чистил кеш и т.д.
Решение которое помогло следующее:
1.выгружаем из ЦБ cf-файл;
2.отвязываем УБ от РИБ (метод УстановитьГлавныйУзел, готовую обработку можно найти в приложении или в других публикациях);
ВАЖНО ***
Перед заменой конфигурации в УБ сделал незначительные изменения (добавил примечание в первом попавшемся документе) , применил эти изменения, а затем уже следующие шаги.
3.заменяем конф. УБ на выгруженный в первом шаге cf-файл, для этого пользуемся меню "Загрузить конфигурацию из файла" (а не сравнением-объединением!!!);
восстанавливем признак РИБ для УБ.
После всего - обмен пошел
Столкнулся с такой-же проблемой. ни 1 ни 2 способ не помог. После всяких экспирементов, оказалось что в УБ после полной загрузки и подключения главного узла отличалась конфигурация (незнаю наверно какойто баг в платформе). Через сравнение конфигураций увидел что отличие в справочнике который недавно рекдактировался. Отключил в УБ центральный узел, просто добавил реквизит на форму того справочника где были отличия, обновил УБ. Потом заново загрузил cf из рабочей базы, подключил главный узел. Сравнил в конфигураторе УБ cf из ЦБ , теперь уже отличий небыло!!!. Попытался загрузить файл обмена, и опачки! он загрузился.
платформа --- 1С:Предприятие 8.3 (8.3.5.1248)
платформа --- 1С:Предприятие 8.3 (8.3.5.1248)
В 8.3 1C себя ведет странным образом
Шаги идут стандартно:
1. Отключить Главный Узел
2. Загрузить конфигурацию
Если на этом этапе сравнить конфигурации - они будут идентичными
3. Подслючить Главный Узел
Если на данном этапе сравнитьь конфигурации - они будут отличаться
PS. Удалось выяснить, что в 8.3.5.1248 нормальным образом не работает "Загрузить конфигурацию из файла..." в части создания новых объектов. Поэтому процедура видоизменяется примерно так. Точность не гарантирую, потому что воспроизвести не могу после исправления
1. Отключить главный узел
2. Сравнить, объединить с конфигурацией из файла... - создаются новые объекты из-за ошибки в Загразить концигурацию
3. Обновить конфигурацию базы данных
4. Загрузить конфигурацию из файла...
5. Обновить конфигурацию
6. Подключить главный узел
Шаги идут стандартно:
1. Отключить Главный Узел
2. Загрузить конфигурацию
Если на этом этапе сравнить конфигурации - они будут идентичными
3. Подслючить Главный Узел
Если на данном этапе сравнитьь конфигурации - они будут отличаться
PS. Удалось выяснить, что в 8.3.5.1248 нормальным образом не работает "Загрузить конфигурацию из файла..." в части создания новых объектов. Поэтому процедура видоизменяется примерно так. Точность не гарантирую, потому что воспроизвести не могу после исправления
1. Отключить главный узел
2. Сравнить, объединить с конфигурацией из файла... - создаются новые объекты из-за ошибки в Загразить концигурацию
3. Обновить конфигурацию базы данных
4. Загрузить конфигурацию из файла...
5. Обновить конфигурацию
6. Подключить главный узел
сталкивался с подобной проблемой, методика первая правильная, но пропущен пункт в самом начале перед радикальными методами нужно почистить кэш в users. вот после чистки пробовать грузить cf в уд из цб и далее по методе.
Да все проще ,
1.добавьте в в конфигураторе в ЦУ любой комент к любому документу
2.Запустите ЦУ в режиме предприятия с параметром ЗапуститьОбновлениеИнформационнойБазы
3.Сделайте обмен в ЦУ
4.Сделайте обмен в УБ
5.УБ запросит обновление базы,обновите
6.Сделайте контрольные обмены
Все ОК
1.добавьте в в конфигураторе в ЦУ любой комент к любому документу
2.Запустите ЦУ в режиме предприятия с параметром ЗапуститьОбновлениеИнформационнойБазы
3.Сделайте обмен в ЦУ
4.Сделайте обмен в УБ
5.УБ запросит обновление базы,обновите
6.Сделайте контрольные обмены
Все ОК
(84) pavelyar, бесплатный совет: не стоит изображать профессора, просто надев очки, нацепив мантию и взяв в руки указку...
То, о чём вы говорите - это первое, что пытаются сделать все, когда возникают проблемы с РИБ...
А в контексте данной статьи - это даже не первый, а "минуспервый" шаг, потому что нулевой - это чистка кэша (как недавно справедливо заметил коллега sergik_nsk).
Так что, коллега, поскромнее немного будьте, в этой жизни не всё так просто, как кажется на первый взгляд...
То, о чём вы говорите - это первое, что пытаются сделать все, когда возникают проблемы с РИБ...
А в контексте данной статьи - это даже не первый, а "минуспервый" шаг, потому что нулевой - это чистка кэша (как недавно справедливо заметил коллега sergik_nsk).
Так что, коллега, поскромнее немного будьте, в этой жизни не всё так просто, как кажется на первый взгляд...
(85) Да я и не изображал собственно из себя никого..
Просто написал что помогло мне,если Вас обидели слова "Да все проще" то я относил это к тому что если возникает ошибка "Конфигурация не соответствует ожидаемой" что бы не парится с остальными способами...
Как бы такого совета я тут не увидел и даже в коментах, где там он как минус первый указывается я тоже не нашел..
Дак вот все шаги я от и до прошел, не один не помог, помог только мой(с) способ,попутно очищая сбойную отправку Digest1 и Digest2 блоков из ЦУ в УБ в тот момент когда "Конфигурация не соответствует ожидаемой"..
Просто написал что помогло мне,если Вас обидели слова "Да все проще" то я относил это к тому что если возникает ошибка "Конфигурация не соответствует ожидаемой" что бы не парится с остальными способами...
Как бы такого совета я тут не увидел и даже в коментах, где там он как минус первый указывается я тоже не нашел..
Дак вот все шаги я от и до прошел, не один не помог, помог только мой(с) способ,попутно очищая сбойную отправку Digest1 и Digest2 блоков из ЦУ в УБ в тот момент когда "Конфигурация не соответствует ожидаемой"..
(86) pavelyar, на ИС не принято вступать в беседу в стиле "ща я вас, салаги, тут всех жизни научу". Это просто считается моветоном и к моим чувствам (обиды) никак не относится.
Теперь про озвученный совет:
Резюме: всё описанное не более чем "танцы с бубном", непонятно за счет чего приведшие к какому-то положительному результату. По такой же логике древние шаманы вызывали дождь.
Теперь про озвученный совет:
- добавить "любой комент к любому документу" - это значит просто инициировать обмен накопительных изменений метаданных между узлами РИБ;
- параметр "ЗапуститьОбновлениеИнформационнойБазы" вообще не относится к платформенным параметрам, а просто запускает в пользовательском режиме последовательность процедур обновления ИБ в пользовательском режиме из набора функций БСП, соответственно и исправить в обменных механизмах он ничего в принципе не может, и отработает только на конфигурациях, написанных под БСП.
Резюме: всё описанное не более чем "танцы с бубном", непонятно за счет чего приведшие к какому-то положительному результату. По такой же логике древние шаманы вызывали дождь.
(84)
У нас УТ 10 и перешли на 8.3.11 с 8.3.8, слетел обмен. Согрешил и динамически(делаю так всегда) сохранял наработки. Короче все к одному слетел обмен. Уверен на 99.9% из-за обновления платформы. пункты 1 и 2 не помогли, думаю как было сказано выше кем то, что новые платформы вносят какието свои изменения и причина в обновлении платформ. В общем зашел в ЦБ в документ поставил пробел в описания какогото поля(выгнал всех с базы). Сохранил, выгрузил из ЦБ и УРА!!! загрузил в УБ там F7. все заработало.
У нас УТ 10 и перешли на 8.3.11 с 8.3.8, слетел обмен. Согрешил и динамически(делаю так всегда) сохранял наработки. Короче все к одному слетел обмен. Уверен на 99.9% из-за обновления платформы. пункты 1 и 2 не помогли, думаю как было сказано выше кем то, что новые платформы вносят какието свои изменения и причина в обновлении платформ. В общем зашел в ЦБ в документ поставил пробел в описания какогото поля(выгнал всех с базы). Сохранил, выгрузил из ЦБ и УРА!!! загрузил в УБ там F7. все заработало.
1.параметр "ЗапуститьОбновлениеИнформационнойБазы" - рекомендует сделать сама 1С перед обменом с узлом РИБ в ЦБ, ну да Вам виднее,я просто салага..который цитирует саму платформу..
2.инициировать обмен накопительных изменений метаданных между узлами РИБ; - помойму это и надо сделать когда УБ не может принять сбойный Digest1 и Digest2 и ручное ковыряние файла обмена приводит к ошибке обмена "файл обмена был некорректно изменен", да и ковыряние скажем в 800 метровом файле не представляется возможным..
3.А всё остальное - и есть все остальное которые делает админ РИБ при возникновении проблем с обменами.
Резюме: помойму все выше описанное с самого начала и есть "танцы с бубном"
В стиле "ща я вас, салаги, тут всех жизни научу" ого это уже фантастика...
Перед кем мне еще надо извинится что бы Вы не выдумывали за меня мои выражения?
P/S Спасибо Вам за советы ,статья действительно очень познавательна! не в коем разе не хотел что либо очернить в выше описанном.
2.инициировать обмен накопительных изменений метаданных между узлами РИБ; - помойму это и надо сделать когда УБ не может принять сбойный Digest1 и Digest2 и ручное ковыряние файла обмена приводит к ошибке обмена "файл обмена был некорректно изменен", да и ковыряние скажем в 800 метровом файле не представляется возможным..
3.А всё остальное - и есть все остальное которые делает админ РИБ при возникновении проблем с обменами.
Резюме: помойму все выше описанное с самого начала и есть "танцы с бубном"
В стиле "ща я вас, салаги, тут всех жизни научу" ого это уже фантастика...
Перед кем мне еще надо извинится что бы Вы не выдумывали за меня мои выражения?
P/S Спасибо Вам за советы ,статья действительно очень познавательна! не в коем разе не хотел что либо очернить в выше описанном.
Подскажите пожалуйста по 2-й методике решения проблемы "Конфигурация узла распределенной ИБ не соответствует ожидаемой" не понял пункт:
6. обязательно перезаписываем файл обмена из УБ (2-й пункт)! этот файл не должен быть загружен при обмене в ЦБ!
Т.е. до этого пункта все сработало и УБ приняло файл из ЦБ на который раньше ругалось, а вот теперь формирую файл в УБ и при его загрузке в ЦБ та ругается так же. А написано что файл "не должен быть загружен в ЦБ" - а какой файл в ЦБ тогда грузить чтобы она следующие файлы обмена корректно формировала?
6. обязательно перезаписываем файл обмена из УБ (2-й пункт)! этот файл не должен быть загружен при обмене в ЦБ!
Т.е. до этого пункта все сработало и УБ приняло файл из ЦБ на который раньше ругалось, а вот теперь формирую файл в УБ и при его загрузке в ЦБ та ругается так же. А написано что файл "не должен быть загружен в ЦБ" - а какой файл в ЦБ тогда грузить чтобы она следующие файлы обмена корректно формировала?
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
|
Перенос данных КА 1.1 => КА 2 / УТ 11 (перенос документов, начальных остатков и справочной информации из "1С:Комплексная автоматизация", ред.1.1 в "1С:Комплексная автоматизация", ред. 2.х)
|
Перенос данных КА 1.1 => КА 2 / УТ 11 (перенос документов, начальных остатков и справочной информации из "1С:Комплексная автоматизация", ред.1.1 в "1С:Комплексная автоматизация", ред. 2.х)
Открыть