Основной темой прочтения была тема: //infostart.ru/public/65458/ , но решение там не было найдено.
После обмена данными из 12 баз была получена информация только от 10.
1 периферийная база не обновилась и от одной уже центральный узел не мог получить данные, хотя сама база обновилась.
А что было? А было динамическое обновление.
Решение кратко:
Внести МОНОПОЛЬНО какое-то изменение в центральную базу (можно поставить пробел в любом месте) и сохранить базу. Выгрузить cf и загрузить во все периферийные базы, сделать монопольно обмен и монопольно обмен в центральной.
Решение подробно:
1. Выгрузить из главной базы конфигурацию: Зайти в конфигуратор, пункт «Конфигурация», «Выгрузить в файл» и переписать конфигурацию в филиал.
2. Закрыть в филиале все сессии 1С и открыть в режиме Предприятие под полными правами обработку «УстановитьГлавныйУзел», ничего не выбирая, нажать кнопку «Выполнить».
3. Запустить Конфигуратор, пункт «Конфигурация», «Загрузить конфигурацию из файла», после загрузки нажать сохранить (дискетка) и нажать F7 (Обновить)
4. Снова открыть в режиме Предприятие под полными правами обработку «УстановитьГлавныйУзел», выбрать центральный узел и нажать кнопку «Выполнить».
5. Сделать обмен в этой базе, после чего выполнить обмен в центральной. Все изменения должны загрузиться.
Обработку для установки главного узла можно взять из той же темы: //infostart.ru/public/65456/
P.S. Через неделю еще у одного клиента возникла та же проблема. Решение помогло.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Тоже была такая проблема. Решение полностью рабочее.
Но мы к сожалению не смогли определить причину возникновения этой ошибки. Она у нас появлялась и при отсутствии динамических обновлений.
Поэтому мы сделали следующее. Все изменения, которые хотим внести, собираются в отдельной копии сотрудниками отдела. А потом разом переносятся в главный узел через сравнение и объединение. Ну а потом уже обновление. Логика в том, что бы не нажимать на кнопку сохранить(дискета) в главной узле более одного раза. Такое чувство, что ошибка кроется там.
Да согласен решение рабочее,можно даже ещё проще делать, у меня 21 узел. и к сожалению такое часто бывает. 1-2 узел стабильно «заболевает». Принято решение добавлять реквизиты максимум 1 раз в неделю и обновляться динамически не чаще 1 го раза в день. Не уверен что проблема в кнопке «сохранить». Это скорее проблема динамического обновления. Мы используем хранилище конфигураций, там кнопка «сохранить» в принципе не работает.
К сожалению, Ответа на вопрос: «Как делать так, что бы базы не «заболевали»?» -мы так и не нашли, И не даёт ответ на этот вопрос данная статья!
Заметил такую особенность, что если платформа главного узла и подчиненного отличается, то данная ситуация происходит намного чаще.
Вместо обработки «УстановитьГлавныйУзел» можно использовать параметр запуска конфигуратора ResetMasterNode — помогает когда после неудачного обновления не получается войти в режиме предприятия.
Внимание! После платформы 8.3.4.1860 ResetMasterNode перестал работать, а разработчики никак не починят. Поэтому используйте старые версии платформы если в текущей не отстегнулось.
И еще из личного опыта:
Не всегда удается загрузить cf в подчиненный узел. Т.е. он загружается, но в файле обмена все равно присутсвует старый идентификатор версии конфигурации. Либо головная база «теряет» у себя этот идентификатор. И после того как вгрузили cf — ничего не работает.
В этом случае помогает чистка кеша.
Для файловой базы в папке с базой оставляем единственный файл 1Cv8.1CD (не забываем делать копии!!!) и при запуске 1С в окне выбора баз удаляем и заново создаем строку подключения. Это помогает и для клиентов серверных баз.
-или-
Пользовательский кеш находится в C:UsersЮзерAppDataRoaming1C1cv8 — каждая база в отдельной папке. Имена папок в виде гуидов, но разобраться вам поможет файл C:UsersЮзерAppDataRoaming1C1CEStartibases.v8i
Для серверной базы — удаляем из консоли администрирования (оставляем базу, без изменений) и создаем заново.
-или-
Серверный кеш находится на сервере в C:Program Files1cv8srvinfo
eg_1541 — для каждой базы своя папка, изучите 1CV8Clst.lst. Остановить службу и вычистить содержимое нужной папки. Помним про копии.
(1) Возможно. При описанных мною действиях кнопка сохранить нажимается 1 раз.
А что здесь нового? Этому решению уже дцать лет: 5 лет назад как минимум уже был известен, когда я только начинал с 1С работать
Сколько раз ни сталкивался — всегда помогало просто загрузить cf из центральной плюс почистить кэши, если они сбойнули после динамических обновлений. Про «кучу материалов» — первый раз слышу. Всегда одинаково лечилось.
от боянище то какой )
Зачастую достаточно в периферийной базе в режиме конфигуратор нажать кнопочку Обновить конфигурацию базы данных.Одна из причин подобных сбоев — некорректная работа антивирусных настроек.
(1) ЭЭЭЭЭЭ…….
Хранилищем не пробовали пользоваться…..всеми сотрудниками отдела из 20 человек работаем уже 5 лет с одной базой ,
никаких проблем нет и не было ни когда ) Центральная база накатывается из хранилища, потом идут обмены со всеми.
Ну разве , что само хранилище падает раз в год!) Но это ни на, что не влияет ни на наши копии ни на рабочие базы.
Создаем новое и понеслась.
(10) Честно говоря нет. Но обязательно попробуем. Спасибо за совет.
Последний раз когда отключал изза такой проблемы главный узел в Рознице, центральный узел риб пропал из списка вообще, хорошо была резервная копия базы риб, оттуда перегрузил узлы в рабочую, но слетели номера сообщений, тоже пришлось поправлять…
Автор — молодец,если допер сам. Для остальных: источник знаний ИТС. Смотри статью
та же проблема. не помогла чистка кеша на клиентах и сервере, не выгрузка цфки из центрального узла в периферийный.
обмен работал в одну сторону, из центральной в периферийною изменения конфигурации приходили, а из периферийной документы нет.
следовательно изменения в центральной как описано в статье и применения их в периферийной тоже не помогли.
решением проблемы было выгрузка цфки из периферийной в центральною.
не знаю как в других, но в РТ2.2 при отвязке узла от центра, при перезапуске выходит предложение о восстановлении РИБ, при отказе узел в плане обмена удаляется
Проблема, как я понял, в том, что при динамическом обновлении конфигурации не пересчитывается (а может не всегда пересчитывается) контрольная сумма Digest1.
Решаю так: в центральной базе добавляю и тут же удаляю реквизит/константу.
При этом при сохранении, С РЕСТРУКТУРИЗАЦИЕЙ, контрольная сумма Digest1 конфигурации обновляется. Затем повторно выгружаю данные на филиалы.
(16) Пробовал подменить хэш — не помогло
(17) Я подменять в файле тоже пробовал. Только сохранение конфигурации с реструктуризацией помогало.
Качать отбработку, которая выполняет одну строчку кода? Оригинально…
50 РИБ. Структура узлов 4х-уровневая (в виде дерева). В моем случае ошибку можно получить таким способом:
1. Меняем конф-ю центрального узла (1ый уровень), эти изменения уходят на следующий уровень.
2. Принимаем изменения на 2ом уровне (в одной из баз), эти изменения уходят на 3ий уровень, но изменения не принимаем.
3. Меняем конф-ю центрального узла (1ый уровень), эти изменения вновь уходят на следующий уровень.
4. Принимаем изменения на 2ом уровне (в той же базе), эти изменения тоже уходят на 3ий уровень (изменения из п. 2 всё еще не приняты)
5. Принимаем изменения на 3м уровне. Но один ход пропущен… Возникает ошибка.
Коллеги, столкнулся с подобной проблемой, но обработка смены гл.узла не работает. как отвязать узел? конфигурация УТ10.3 платформа 8.3.12
(21) пардон, скосячил, все работает
(15)
В УТ 11.4 та же беда
Ну так, на всякий случай, вдруг кому пригодится.
Делал я тут позанадысь свёртку базы. Останавливать работу юзеров надолго нельзя, поэтому замутил тестовую базу, выгрузил туда рабочую, настроил обмен между ними — а он не работает. Тоже пишет, что не соответствует конфигурация (собственно, в поисках решения этой беды гугл меня сюда и послал). Как так, база-то вообще та же самая по факту, ничего же не должно отличаться! Подчинённый-главный, коды обменов, настройки транспорта — всё как положено, всё проверил. А не работает. Выгрузка — загрузка конфигурации, по рецепту автора, не помогла. А потом обнаружилось, что по недогляду я тестовую базу поднял на более свежем релизе платформы, чем тот, на котором рабочая база крутится. Поставил на том же релизе, что и боевая база — и всё заработало, обмены пошли. Даже выгрузку рабочей базы заново делать не пришлось, ту же загрузил.
Всем привет. толи лыжи не едут то ли я что не так делаю(
Всё делаю как написано
обработкой снимаю главный узел
захожу в конфигуратор а база как была не редактируемая так и осталась.
изменения конфигурации заблокированы средствами управления распределённой ИБ
и не могу следовательно с центральной загрузить CF
видимо я олень
(25) Значит главный узел не снялся.
Добавь сообщения об ошибках в обработку.
Почисти кэш у пользователя и у базы
Короче после долгих извращений. Чистки кеша. Запуска этой обработки по снятию узла. Результата 0. Со психу я поднял базу с бэкапа. Думаю ладно еще раз попробую. Запустил обработку снял узел. Захожу в конфигуратор и вуаля получилось. Залил конфу. Запустил предприятие востановил связь и пошел обмен. До сих пор не могу понять что было.
на сервере платформа 8.3.14.1565 на рибе платформа 8.3.14.1779 синхронизация не работает пишет»Конфигурация узла распределенной ИБ не соответствует ожидаемой» , что это может быть и как с этим бороться ?
(28) Конфигурация узла не соответствует ожидаемой — это когда у вас пришло сообщение обмена в распределенную базу и в ней работали несколько пользователей. Приложение было запущено не монопольно и не смогло обновить вашу базу. Нужно всех выгнать из базы, зайти в конфигуратор и нажать F7
(28)
На 8.3.14 версии платформ ЦБ и узлов должны быть идентичны, иначе вот такое вот сообщение и оно не обязателньо означает, что необходимо реанимировать узел.
(29)
Вы ошибаетесь, это сообщение свидетельствует о рассинхронизации конфигураций.
Для серверной базы — удаляем из консоли администрирования (оставляем базу, без изменений) и создаем заново — помогло только это, выгрузкизагрузки конфигурации не спасли.