Изменения заблокированы средствами управления распределенной иб. Для профилактики проблем, вызывающиех эту ошибку, рекомендуется не делать динамическое обновление(как минимум несколько раз подряд — до загрузки изменений в филиалы), а также желательно в на

Для начала привожу список используемых мной сокращений:

• РИБ - распределенная информационная база
• ЦБ - центральная база, корневой узел РИБ
• УБ - удаленная база, БД удаленного узла РИБ

По собственному опыт могу сказать, что сталкивался с двумя причинам возникновения ошибки:

1. во время приёма файла сообщения в УБ "упала" база, в связи с чем, видимо, и произошла разсинхронизация между конф. ЦБ и УБ;
2. под MSSQL клиент загрузил копию рабочей базы и не выключил в копии регл. задания автообмена, в результате часть сообщений в удаленные узлы формировалась из рабочей БД, а часть из копии, что и привело рассинхронизации конфигураций

Есть также мнение, что к этой ошибке приводит использование механизма динамического обновления базы. Здесь есть сомнения, потому как с одной стороны динамическое обновление никогда не затрагивает структуры БД, а механизмы РИБ всё-таки работают именно со структурой БД, а не с прикладной её частью, тем не менее в РИБ используется механизм формирования цифровой подписи версии конфигурации (в дальнейшем буду называть её для сокращения хэшем), и при изменении прикладной части хэш естественно обязан пересчитаться. Не буду ни отрицать этого, ни утверждать, т.к. если и сталкивался с этой ситуацией, то явных доказательств этого не нашел.

Для исправления использую 2 методики, в зависимости от ситуации.

ПЕРВАЯ МЕТОДИКА

Первая (самая распространенная) неоднократно упоминается и в партнерской конференции, и на прочих интернет-ресурсах связанных с 1С. Применяется в большинстве случаев, когда несмотря на сообщение о расхождених конфигураций, при сравнении вручную выдается, что они идентичны.

Последовательность действий:

1. выгружаем из ЦБ cf-файл;
2. отвязываем УБ от РИБ (метод УстановитьГлавныйУзел, готовую обработку можно найти в приложении или в других публикациях);
3. заменяем конф. УБ на выгруженный в первом шаге cf-файл, для этого пользуемся меню "Загрузить конфигурацию из файла" (а не сравнением-объединением!!!);
4. восстанавливем признак РИБ для УБ.

В большинстве случаев этих действий более чем достаточно, что восстановить обмен, но не всегда...

ВТОРАЯ МЕТОДИКА

Применяется в случае, если первая методика не сработала, а выгрузить заново узел не представляется возможным.

Предыстория: у клиента настраивали каскадную РИБ и ошибка возникла в первом уровне каскада (второй уровень всё это время работал безупречно). Разработка конфигурации велась совместно с IT-службой клиента и с момента возникновения ошибки конфигурация ЦБ успела несколько раз поменяться. Вариант с откатом изменений не рассматривался даже в принципе, т.к. потеря части данных и остановка работы нескольких подразделений были совершенно неприемлимы. Первый вариант исправления ошибки каких-либо ощутимых результатов не дал. В связи со чем пришлось искать другие пути решения.

Пришла мысль попробовать подменить хэши файлов конфигураций непосредственно в XML-файлах обмена. Описание структуры файла обмена из книги "Профессиональная разработка в системе 1С:Предприятие 8" дало слабое представление о формировании цифровых подписей конфигураций и изменений в них, но определило направление поиска: значения Digest1 и Digest2. Всё остальное выяснял чисто эмпирическим путём (то бишь методом проб и ошибок), но закономерность установить таки получилось.

Тестовые эксперименты прошли удачно. На рабочих базах тоже всё прошло благополучно.

Итак, последовательность действий:

1. выполняем действия 1 - 4 первой методики;
2. выгружаем из УБ файл обмена, но не загружаем его в ЦБ;
3. выгружаем из ЦБ файл обмена, но не загружаем его в УБ;
4. в файле обмена из ЦБ заменяем блок, содержащий информацию об изменениях конфигурации и хэши (Digest1 и Digest2), на блок хэшей из файла УБ (пример см. ниже)
5. производим загрузку файла из 4-го пункта в УБ;
6. обязательно перезаписываем файл обмена из УБ (2-й пункт)! этот файл не должен быть загружен при обмене в ЦБ!
7. для проверки делаем несколько последовательных обменов.

Если при обмене используется сжатие данных, то либо отключаем сжатие, либо сначала распаковываем файл, меняем, потом запаковываем обратно и отправляем.

Блок файла обмена из ЦБ

106.0
...здесь идут блоки описания изменений конфигурации...
1cf680807e97a5dc0d1ed7f901b07392
038211651cf680807e97a5dc0d1ed7f9

нужно заменить на блок файла обмена из УБ (обратите внимание Digest1 у файла из УБ всегда равен "00000000000000000000000000000000"!!!)

106.0
00000000000000000000000000000000
11651cf680807e97a5dc0d1ed7f901b0

Перечисленные действия необходимо выполнять с предельной осторожностью, некорректная последовательность чревата полной неработоспособностью РИБ. Поэтому перед этими действиям создание резервных копий ОБЯЗАТЕЛЬНО!

В остальном могу только пожелать удачи!

Ошибки динамического обновления (или другие глюки платформы) могут быть причинами ошибок обмена распределенных информационных баз:

• "Данные принимаются от узла, для которого зарегистрированы изменения конфигурации"
  

• "Конфигурация узла распределенной ИБ не соответствует ожидаемой"
  

Как восстановить обмен?

Но начнем не с воостановления, а с возможности провести о бмен "вручную", что бывает важно в течении дня, потому что, как всегда, всё должно работать "еще вчера":) Сделать это можно с помощью замечательных обработок, которые я не пом ню где скачал(авторы, откликнитесь — оставлю ссылки на ваш ресурс, а с моего, если нужно — удалю ). Обработки дают возможность выгрузить только зарегистрированные изменения данных в базе(по указанному плану обмена для определенного узла!) в XML без выгрузки изменений конфигурации и, если объекты конфигурации не сильно видоизменились, то есть очень большие шансы на загрузку этих данных. Обрабокти эти можно скачть по ссылке в конце статьи.

Что касается восстановления. Есть более простые способы, включающие не все пункты приведенного ниже списка, но они не всегда помогают, как например было в одном из моих случаев. Поэтому привожу тот способ, который помог мне, он обходит возможные проблемы более комплексно. Далее по шагам.

Делать указанные шаги желательно тогда, когда в базе не будет работающих пользователей. Если это невозможно, то Вам придеться "допилить" метод под себя, а следовательно нужно сначала понять его логику.

1. Сделать резервные копии везде.

2. Для клиент-серверов: отключить базы через "администрирование сервера" и сразу подключить с установкой блокировки регламентных заданий(таким образом сбросится кэш сервера). После этого не забыть перекинуть в новый каталог журнал регистрации.

3. На всех используемых для восстановления компах удалить базу в списке баз стартера 1С и создать поновой(очистится кеш пользователя)

4. В конфигураторе(в центральной базе) добавить новую константу сохранить изменения конфы.

5. Очистить все каталоги обмена.

6. Сделать выгрузки во все филиалы(пока только выгрузки).

7. Попробовать загрузить(только загрузить) полученные данные во все филиалы. Естественно принять изменения конфы.

Если везде все хорошо, идем далее, если все плохо — думаем, может быть поможет выгрузка.cf из центральной базы и её ЗАГРУЗКА в филиал(не сравнение-объединение). В подчиненном узле следует отвязать базу от РИБ (поможет в этом обработка — скачать по ссылке ниже). Статья на эту тему есть на infostart.ru.

8. Отменяем регистрацию изменений для филиалов в ЦБ(ведь все изменения мы уже везде получили). Важно сделать на этом этапе, чтобы накопившиеся изменения из разных филиалов попали в другие филиалы. (скачать обработку для отвязки-привязки по ссылке ниже).

9. Делаем загрузку в ЦБ и если все хорошо, то делаем загрузку-выгрузку с каждым филиалом несколько раз для закрепления результата.

10. Всё.

Можно включить выполнение регламентных заданий у клиент-серверных баз.

Для профилактики проблем, вызывающиех эту ошибку, рекомендуется не делать динамическое обновление(как минимум несколько раз подряд — до загрузки изменений в филиалы), а также желательно в настройках обмена поставить галочку"выгружать данные только при успешной загрузке".

Вопрос: Ошибка обновления узла РИБ

Добрый день.

Обновил основной узел Рарус-Розницы до 2.2.5.27, сделал обмен с парочкой узлов РИБ - все отлично.

Начал массовое обновление остальных узлов (аналогичных "верхней парочке" (другие магазины по РИБ)) - в клиентской части выскакивает ошибка:

РассылкаОтчетов.ЗарегистрироватьДанныеДляАктуализацииСпискаРегламентныхЗаданий"
отложенного обработчика обновления
"РассылкаОтчетов.АктуализироватьСписокРегламентныхЗаданий"
произошла ошибка:
"{ОбщийМодуль.ОбщегоНазначения.Модуль(3502)}: Ошибка при вызове метода контекста (Содержит)
Возврат Метаданные.РегистрыСведений.Содержит(ОбъектМетаданных);
по причине:
Несоответствие типов (параметр номер "1")".

Может кто сталкивался? Пробовал уже и платформу обновлять (до максимальной 8.3.10, и проверял на 32-64 компах)... не помогло. Но ведь тестовые 2 магазина без проблем обновились, не могу понять как так.

Ответ: () Я так и устанавливаю главный узел. Я немного о другом писал: после того, как обработкой узел отвязываешь, при следующем запуске не сразу начинается обновление конфы, а сначала 1С открывает окно, в котором просит подтвердить, что узел отвязывается. После этого обновляется - после обновления узла в списке уже нет.
На самом деле, на 2.1, помню, что обновлял таким методом, но вот на 2.2 что-то не взлетело. Может, по запарке уже и тыкал неправильную последовательность произвел в действиях)

ПО САБЖУ:
Разобрался с тем, что есть. Оказалось, что недоглядел:
"В одном из релизов 2.2 появился справочник Рассылки отчетов с предопределенным элементом "Личные данные"" - справочник с этим элементом был и на 2.1.

Нюанс такой: косяки с обновлением узлов наблюдаются на тех базах, которые создавались из центральной именно на релизе 2.1.9.18. Все, что создавалось на более ранних релизах - обновилось нормально. Это, наверное, и объясняет, почему пара баз у ТС тоже обновились успешно, а потом пошли косяки.

Ничего выдумывать с созданием нового элемента в справочнике и установкой его как предопределенного не стал. Перенес из копии центра на 2.1 через выгрузкузагрузкуXML этот элемент и повторил обновление на проблемной "базе" - все прошло.

() Так что пользуйся методом, если еще не нашел ответ.

Вопрос: Ошибка обновления конфигурации

Делаю обновление конфигурации Бухгалтерия 2.0.64.14 на 2.0.64.24. платформа 8.2.19
Сразу возникает ошибка:
Ошибка доступа к файлу... путь... временный файл.tmp.
Куда смотреть?

Ответ: решил тот раз проблему дождавшись нового "стабильного" релиза

Вопрос: Ошибка в правах пользователя на БСП

Приветствую вас!!! Пишу конфу на базе БСП 2.2, вроде бы уже и опыт есть, и доки вдоль и поперек изучил, но при первом запуске ИБ вылетает ошибка:

{ОбщийМодуль.ПользователиСлужебный.Модуль(345)}: Авторизация не выполнена. Работа системы будет завершена.
Пользователь: Администратор не найден в справочнике "Пользователи".

При попытке добавления пользователя в справочник возникла ошибка:
"Ошибка обновления информационной базы.
Не заполнен параметр ограничения доступа:
"Возможные права для настройки прав объектов".

Для разработчика: возможно требуется обновить вспомогательные данные,
которые влияют на работу программы. Для выполнения обновления можно:
- воспользоваться внешней обработкой
"Инструменты разработчика: Обновление вспомогательных данных",
- либо запустить программу с параметром командной строки 1С:Предприятия 8
"/С ЗапуститьОбновлениеИнформационнойБазы",
- либо увеличить номер версии конфигурации, чтобы при очередном запуске
выполнились процедуры обновления данных информационной базы."

Нажмите, чтобы раскрыть...

Хотелось бы услышать ответы "бывалых", для последующего активного диалога, возможно даже сотрудничество

Ответ:

Vdeg сказал(а):

Проблема решилась?

У меня проблема другого плана: добавляю пользователя в БСП 2.2.5.29, а он у меня либо имеет полные права (если вручную добавить их), либо вообще никакие (видит пустой интерфейс без единого справочника и документа). Потому что в типовых ролях БСП вообще нет никаких галок для доступа к конкретным (моим) справочникам и документам. Как же тогда доступ на уровне записей для нового пользователя будет отслеживаться???

Нажмите, чтобы раскрыть...

А откуда БСП должна узнать, что у вас за справочники и как вы хотите настроить им доступ?
Наверное самим надо это сделать

Вопрос: ОтправкаДоставляемыхУведомлен Удаленный узел не прошел проверку

До прошлой пятницы следующий код прекрасно работал..

XdtoПодписчик = ФабрикаXDTO.Создать(ФабрикаXDTO.Тип(";));
xdtoПодписчик.DeviceID = DeviceID;
xdtoПодписчик.SubscriberType = ФабрикаXDTO.Создать(ФабрикаXDTO.Тип(";), "GCM");
НовыйСериализаторXDTO = Новый СериализаторXDTO(ФабрикаXDTO);
Подписчик = НовыйСериализаторXDTO.ПрочитатьXDTO(xdtoПодписчик);
Уведомление=Новый ДоставляемоеУведомление;
Уведомление.Получатели.Добавить(Подписчик);
Уведомление.Текст=Текст;
Уведомление.ЗвуковоеОповещение=ЗвуковоеОповещение.ПоУмолчанию;
Уведомление.Наклейка=1;
ДАнныеАуз=ТОКЕН;
ОтправкаДоставляемыхУведомлений.Отправить(Уведомление,ДАнныеАуз,Истина);

Теперь ошибка Удаленный узел не прошел проверку. Сломал всю голову. Ловил обращения сервера - пусто такое ощущение что он никуда не обращается... Пробывал на трех разных машинах с разными осями. иссяк.. помогите...

Ответ: Вверх

Ответ: Так, решил сделать образ узла заново. При запуске узла пишет, что нужно запустить с \c запуститьобновлениеинформационнойбазы
и сделать образ заново.

Получается это что то из-за кривого обновления.

Я попробовал запустить с этим ключем и сделать обмен с существующим узлом. В узле никакие обновления не запустились, ничего перезапускать не попросил.

И в итоге в главном узле сообщение опять было не принято с той же ошибкой.

Что можно сделать?
Может изменить в главном узле фиктивно что то в конфе и сделать обмен? Или он не всю конфу обновит а только то что изменю? Я попробую узел пока сделать. Но буду ждать ваших идей

Вопрос: Распределенная база - ошибка при обмене не устраняется

Всем доброе время суток!

Ситуация следующая.

При загрузке обмена из периферийного узла получаю сообщение "Конфигурация узла распределенной ИБ не соответствует ожидаемой".

Дальше действую по инструкции.
Выгружаю конфигурацию из центральной базы в CF, отвязываю периферийную базу от центрального узла обработкой, снимаю конфигурацию в периферийной базе с поддержки, загружаю конфигурацию из файла.
Привязываю в периферийной базе центральный узел обработкой.
Сохранить, применить.

Выгружаю еще раз обмен из центральной базы.
Загружаю в периферийную. Выгружаю обмен из периферийной базы.
Загружаю в центральную. Опять получаю сообщение "Конфигурация узла распределенной ИБ не соответствует ожидаемой".
Но это какой-то реальный бред - я же загружаю конфигурацию в центральную базу и в периферийной базе конфигурацию никто не менял.

Как победить такую ошибку?

Ответ: никому и в голову не пришло советовать столь очевидные вещи после многолетней ругани на демоническое обновление:)

Вопрос: РИБ и обновления

Всем привет. Планируется использование распределенных ИБ.

конфигурация измененная. Обновление конфигурации центральной базы выполняет программист. Затем с файлами обмена эти изменения будут передаваться в периферийные базы.

Вопрос такой: а как быть с запуском обработчиков после обновления конфигурации базы данных и первого входа в пользовательском режиме?

обновление основной конфигурации - обновление конфигурации базы данных - выполнение обработчиков обновления в пользовательском режиме

Например, было пропущено много релизов, необходимо последовательно обновить обновиться на 3 релиза. Проблем с обновлением центральной базы не возникает, а как быть с переферийными? Необходимо тоже выполнять их обновление в 3 этапа (обновить центральную базу первым релизом, обновить РИБ, обновить центральную базу вторым релизом, обновить РИБ и т.д.?)

Всем спасибо за помощь!

Ответ: () ткните носом, не могу найти код, который выполняется при регистрации изменений объекта.
Думается, что если использовать метод ПриОтправкеДанных, то в главном узле все равно будут копиться измененные объекты для оправки в подчиненный узел. А это лишние ресурсы компа
Поэтому хочу, чтобы объекты в главном узле не регистрировались для отправки уже сразу в момент их изменения (ПриЗаписи, например). В каком месте, например, типовой Бухгалтерии ред.3 эти объекты регистрируются для оправки?

Вопрос: [РЕШЕНО] Ошибка обращения к интернет-поддержке

Уважаемые эксперты, подскажите, пожалуйста!
1С:Предприятие 8.3 (8.3.11.2899)
На сервере 1С крутятся несколько баз разных конфигураций, во всех интернет-поддержка подключена и нормально работает. В т.ч. загрузка курсов валют, банков, проверка контрагентов, СПАРК и т.д.
Настройка прокси во всех базах прописана одинаково.
Но в базах БП-3 КОРП всегда вылетает ошибка:

В журнале регистрации:

Не удалось получить тикет аутентификации в сервисе.
Не удалось загрузить содержимое (). {ОбщийМодуль.ИнтернетПоддержкаПользователейКлиентСервер.Модуль(362)}: Ошибка при вызове метода контекста (ОтправитьДляОбработки)
Ответ = Соединение.ОтправитьДляОбработки(HTTPЗапрос, ПараметрыПолучения.ИмяФайлаОтвета);
по причине:
Ошибка работы с Интернет: Удаленный узел не прошел проверку

Нажмите, чтобы раскрыть...

Пробовал и на разных версиях платформы (8.3.10..., 8.3.11...), и на разных версиях конфигурации (3.0.54.15, 3.0.57.10).
Тестирование и исправление - тоже не помогает.
В чем может быть дело?
Неужели БП-КОРП как-то по-особенному ходит в интернет?
Спасибо.

Ответ:

Ответ от 1С (мне помогло то, что выделено красным):

При переходе было выполнено обновление БСП в составе БП с 2.4.3 на 2.4.4
В списке изменений БСП 2.4.4
Повышена безопасность при установке защищенного соединения с HTTPS интернет-сервисами. При обнаружении различных проблем с сертификатом интернет-сервиса, с которым выполняется попытка защищенного соединения (сертификат не действителен, устарел или не является доверенным), соединение не будет установлено.
В 8.3.10 проверка сертификатов в windows осуществляется средствами операционной системы." -
Установите последние обновления для вашей ОС, В них содержатся важные обновления системных компонент, которые отвечают за работу с сертификатами.
Просьба также установить последние обновление корневых сертификатов, распространямые Microsoft в устанавливаемых пакетах.
Требуется версия не ниже IE8.0. В нем содержатся важные обновления системных компонент, которые отвечают за работу с сертификатами.
Как правило, после установки всех обновлений проблема решается.
Проверьте, что если в строке поиска в интернет эксплорере ввести, то ссылка открывается.
Пользователь, от имени которого вы работаете, имеет доступ в интернет.
В случае, если это файловая база на машине клиента - проверять следует на ней.
Если это клиент-серверная база, то на сервере из- под пользователя, под которым запущен сервер 1С.
Проверять только браузером IE.
Проверьте, что открыты порты 443 и 80
Если используется Прокси -сервер, то проверьте, настроены ли данные в меню Персональные настройки.
Если используется клиент-серверная версия, то следует настроить сервер таким образом, чтобы на нем корректно работало подключение к интернету браузером IE из-под пользователя, от имени которого запущен сервер 1С. ​

Прописал прокси именно в настройках IE пользователя, под которым запущен сервер 1С - всё заработало.

Вопрос: Обновление бух 3

Доброго дня
Бухгалтерия 3
делал обновление с 3.0.43.208 на 3.0.43.235
ошибки
первая
{ОбщийМодуль.ОбменСообщениямиВнутренний.Модуль(381)}: Ошибка при вызове метода контекста (ЭтотУзел)

по причине:
Найдено более одной записи
вторая
При вызове обработчика обновления:
"ОбменСообщениямиВнутренний.УстановитьКодЭтойКонечнойТочки()"
произошла ошибка:
"{ОбщийМодуль.ОбменСообщениямиВнутренний.Модуль(381)}: Ошибка при вызове метода контекста (ЭтотУзел)
Возврат ПланыОбмена.ОбменСообщениями.ЭтотУзел();
по причине:
Найдено более одной записи".

Почитал пишут косяк платформы попробовал на разных версиях платформах
пробовал взять чистую конфу последней версии и просто тупо полной заменой загрузить
вообщем не помогло всегда одно и тоже. Подскажите вдруг кто сталкивался?

Ответ:

узел с истины на ложь поменял выше писал думал не получилось, а потом зашел посмотреть сработало

Распределенная информационная база (РИБ) достаточно часто используется для организации работы филиалов и подразделений, позволяя оперативно обмениваться информацией, сохраняя нужную степень автономности. Несмотря на то, что данная технология достаточно надежна, время от времени ломается и она. Сегодня мы рассмотрим одну из довольно распространенных ошибок: Расскажем о причинах ее возникновения и методах борьбы с ней.

Начнем, как всегда, с начала. После того, как вы создали РИБ все изменения в конфигурацию информационной базы можно вносить только в главном узле. Впоследствии, при следующем обмене, все изменения будут переданы в подчиненные узлы и автоматически применены там. Но гладко было на бумаге...

На практике иногда случается так, что между сеансами обмена, особенно если на периферии плохо с каналом, конфигурация главного узла успевает измениться дважды. Например, внесли изменения, выгрузили, периферийная база изменения получила, но еще не применила их, что может занять некоторое время, и подтверждения еще не прислала. Если в этот промежуток внести изменения еще раз и снова выгрузить обмен, то получится, что центр ожидает увидеть в периферийном узле конфигурацию №1 и попытается обновить ее на конфигурацию №3, а по факту столкнется там с конфигурацией №2. Иногда подобная ситуация возникает при динамическом обновлении центральной базы. В итоге обмен станет невозможным, и вы получите сообщение о том, что Конфигурация узла распределенной ИБ не соответствует ожидаемой!

В общем мораль этой истории проста - не ведите активную доработку рабочей базы, а если ведете, то завершайте все сеансы обмена до внесения следующих изменений. Но как быть, если такая неприятность все-же произошла?

Решение "в лоб" - создать новый образ подчиненного узла, однако на практике он обычно неприменим. Как правило возникновение серьезной ошибки при обмене фиксируется не сразу, а через некоторое время после того, как перестали поступать оперативные данные из периферийных баз. В зависимости от расписания обмена между моментом возникновения проблемы и ее обнаружением может пройти целый рабочий день, а то и более.

Здесь стоит кинуть камень в огород разработчиков, которые выдают как ошибку и точно также подсвечивают красным ситуацию Номер сообщения меньше или равен номеру ранее принятого сообщения , которая в общем-то является вполне нормальной. В итоге у пользователей восприятие ошибок притупляется, и они просто перестают читать выводимые сообщения, считая, что все хорошо и просто другая сторона еще не сделала обмен у себя.

Но вернемся к нашей ошибке. Решение довольно простое и лежит на поверхности: привести конфигурацию периферийной базы к ожидаемой, т.е. привести ее в соответствие с конфигурацией центрального узла. Но на практике сделать это не так просто. Если мы откроем периферийную базу в конфигураторе, то увидим, что изменения заблокированы средствами управления РИБ.

Чтобы изменить конфигурацию подчиненного узла потребуется временно отключить его от центральной базы. Для этих целей можно воспользоваться одной из обработок, которых достаточно представлено в сети, либо отключить ИБ от центрального узла с помощью параметра запуска Конфигуратора /ResetMasterNode .

Откройте командную строку и введите (с учетом версии платформы и реального пути установки):

"C:\Program Files (x86)\1cv8\8.3.6.2100\bin\1cv8.exe" config /ResetMasterNode

После выполнения данной команды появится обычное окно стартера, выберите там нужную базу и нажмите кнопку Конифгуратор .

Запуска ИБ при этом не произойдет , т.е. может показаться, что ничего не произошло, но открыв базу в Конфигураторе повторно, можно убедиться, что она отключена от главного узла и доступна для внесения изменений.

Внимание! На платформах 8.3.7 - 8.3.9 выполнение данной команды приводит к аварийному завершению работы. Ошибка исправлена в платформе 8.3.10.

Если вы не хотите возиться с командной строкой, то можно воспользоваться одной из обработок, ниже представлена та, которую используем мы, она была найдена на просторах сети, и мы внесли в нее лишь косметические правки. Обратите внимание, обработка подходит лишь для обычного приложения, для конфигураций на управляемом приложении используйте ключ запуска Конфигуратора.

Работа с ней предельно проста, запускаем ее в режиме 1С:Предприятия, через Файл - Открыть , затем просто нажимаем нужную кнопку, в нашем случае Отключить главный узел .

Теперь нам потребуется актуальная конфигурация из центрального узла. Для этого откроем центральную ИБ в Конфигураторе и выполним Конфигурация - Сохранить конфигурацию в файл . Полученный файл с расширением cf потребуется передать в периферийный узел.

Затем в периферийном узле запускаем ИБ (предварительно отключив ее от главного узла) в Конфигураторе и снимаем с поддержки. Для этого выбираем: Конфигурация - Поддержка - Настройка поддержки .

В открывшемся окне сначала включаем возможности изменения.

А затем снимаем конфигурацию с поддержки.

Теперь можно загружать конфигурацию из файла, для этого выберите Конфигурация - Загрузить конфигурацию из файла и укажите не переданный из центрального узла cf -файл. После чего вы получите предупреждение о том, что текущая конфигурация не пустая. Обращаем ваше внимание, что проделываемые нами манипуляции потенциально опасны и могут привести к необратимому повреждению ИБ, поэтому перед тем, как продолжать убедитесь, что у вас есть актуальная резервная копия.

Эта ошибка является типичной для . Ошибка «Конфигурация узла распределенной ИБ не соответствует ожидаемой» является системной. В основном возникает из-за аварийного завершения работы во время обмена данными по УРИБ.

Решить это можно достаточно простым способом. Рассмотрим его.

Инструкция

1. Сделайте копии баз, над которыми будут производиться работы (В конфигураторе «Администрирование - Выгрузить информационную базу»).

2. Запустите конфигуратор главной базы узла РИБ.

3. Сохраните конфигурацию центрального узла в файл базы данных («Конфигурация — Сохранить конфигурацию в файл…»)

4. Откройте конфигуратор базы подчиненного узла.

Получите 267 видеоуроков по 1С бесплатно:

5. Снимите конфигурацию подчиненного узла с поддержки (Конфигурация — Поддержка — Настройки поддержки — Снять с поддержки):

6. Загрузите конфигурацию базы данных («Конфигурация — Загрузить конфигурацию из файла…»).

8. После реструктуризации необходимо зайти в режим предприятия и установить главный узел конфигурации. Это сделать можно с помощью специальной обработки — . Обработка работает как в режиме управляемого приложения, так и в режиме обычного приложения.

9. В обработке необходимо выбрать главный узел и нажать «Выполнить»:

10. Готово! Попробуйте запустить обмен, система должна корректно выполнить обмен.