1с ошибка при обновлении риб

Ошибка обновления узла РИБ

Я

   frid

02.07.17 — 14:49

   roman844

1 — 02.07.17 — 17:59

Это 1с тут никто ни в чем не уверен.

   gorakh

2 — 02.07.17 — 18:16

Это ошибка в данных. Остановка по ошибке + Стек вызовов спасет «спасет отца русской демократии» ИМХО в ОбъектМетаданных передается неопределено.

   Cyberhawk

3 — 02.07.17 — 19:48

«Пробовал уже и платформу обновлять» // От безысходности что ли? Так-то у тебя конкретная ошибка в прикадном коде, и тебе доступна возможность выяснить способ ее воспроизведения

   frid

4 — 02.07.17 — 21:37

   Фрэнки

5 — 02.07.17 — 21:40

а сравнить содержимое текста проблемного кода в одном узле и в том, где все прошло нормально?

   gorakh

6 — 02.07.17 — 22:10

(5) Это РИБ (?). Расхождений в коде не может быть по определению.

   Фрэнки

7 — 03.07.17 — 08:46

(6) откуда уверенность, что он это «по определению» обеспечил? Вы у топикстартера из-за его спины видели, как он там в обмены данные узла помечает?

   Serg_1960

8 — 03.07.17 — 09:36

Если говорить о вероятностях, о вероятность не идентичности конфигураций в узлах или о вероятности не использования ошибочного алгоритма в «сделал обмен с парочкой узлов РИБ —

все отлично(цы), то вероятность последнего предположения — выше.

   Serg_1960

9 — 03.07.17 — 09:46

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

   h-sp

10 — 03.07.17 — 10:05

возможно ошибка в программе, по обмену пришел документ, который не предусмотрен в регистре сведений.

   Stanislav1C

11 — 06.07.17 — 10:05

Аналогичная ситуация с этой же ошибкой.

Обновил центр с 2.1.9.18 на 2.2.5.27, дальше 6 подчиненных узлов торговых точек обновились без проблем, на 7м эта ошибка. Сразу решение не нашел, создал по новой начальный образ. А вот на 8м узле уже тупик, т.к. РИБ двухуровневый, и 8я точка является центром для еще Nго числа точек. Поэтому заново создавать всю эту иерархию начальными образами не вариант. Стал копаться в отладчике, дошел до такого результата:

В одном из релизов 2.2 появился справочник Рассылки отчетов с предопределенным элементом «Личные данные». Справочник не включен в состав плана обмена. Соответственно, предопределенный элемент на узле не находится, и передается Неопределено в ОбъектМетаданных, как и говорилось в (2). В настройках справочника — Обновление предопределенных данных стоит Авто, т.е. предопределенные элементы в предприятии создаются при первом запуске базы. Для узла этот запуск не первый,вот и получается, что он не создается. В голову приходит изменить конфу, включив справочник в план обмена. Но конфа типовая, из-за этого момента изменять не хочется. Есть идеи, как решить проблему?

   Фрэнки

12 — 06.07.17 — 10:13

где-то давно попадалось на глаза, что уже созданному элементу справочника возможно установить или убрать признак предопределенного… может получится протестить такой вариант — создать элемент вручную, чтобы ссылка на него в загружаемом пакете была существующей — это надо будет ему гуид от отправителя прописать, наверное.

   Serg_1960

13 — 06.07.17 — 10:18

(11) «В голову приходит изменить конфу» — а мне в голову приходит в типовой поискать обработку обновления, которая включатся для принудительного обновления предопределенных — где-то я однажды такое видел.

   Ёпрст

14 — 06.07.17 — 10:18

(11) отвяжи базу от центра, сделай загрузку cf от центральной, потом обратно привяжи

   Serg_1960

15 — 06.07.17 — 10:22

Странное это утверждение, спорное… В моей конфигурации есть справочники с предопределенными, которые не включены в план обмена — и что? А ничего, с ними нет проблем. Они обновляются при получении обновления конфигурации, а не через планы обмена.

   Stanislav1C

16 — 06.07.17 — 10:41

   Stanislav1C

17 — 06.07.17 — 10:43

   Serg_1960

18 — 06.07.17 — 11:50

(17) Это называется «Чисти кэши!»(с)

   Ёпрст

19 — 06.07.17 — 12:56

(16) зачем «через форму от 1с» ?

там всего-то поделка с одной кнопкой

   Ёпрст

20 — 06.07.17 — 12:59

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

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

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

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. для проверки делаем несколько последовательных обменов.

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

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

            <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>

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

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

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

Прочитав эту статью, вы:

• узнаете о причинах возникновения самой распространенной ошибки РИБ: Конфигурация узла распределенной ИБ не соответствует ожидаемой;
• Получите пошаговые инструкции решения проблемы.

Распределенная информационная база (РИБ)

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

В этих случаях выполняют настройку распределенной информационной базы.

Базу центрального офиса, где собираются все данные, называют центральной, а базы филиалов — периферийными.

Рассмотрим создание РИБ на примере 1С:Бухгалтерия 3.0.

Настройка центральной базы

Настройка РИБ выполняется в разделе Администрирование — Настройки программы —Синхронизация данных — ссылка Настройка синхронизации данных — кнопка Новая синхронизация данных — ссылка Распределенная информационная база.

Перед началом настройки выставляется префикс основной базы, например, ЦБ. PDF

Настройка центральной базы РИБ выполняется по этапам:

Создание начального образа подчиненного узла РИБ занимает много времени. Не пугайтесь, если программа «висит» и «ничего не происходит» — просто дождитесь окончания операции, которая может длиться несколько часов.

Чтобы убедиться, что «все идет по плану», откройте Журнал регистрации: раздел Администрирование — Настройки программы — Обслуживание — ссылка Журнал регистрации. Последние операции в нем будут показывать работу Мастера настройки синхронизации по производимым в это время изменениям в базе данных. PDF

По окончанию операции будет выдано сообщение о ее успешном завершении.

Настройка выполняется в автоматическом режиме Мастером настройки синхронизации, от пользователя требуется следовать указаниям Мастера и нажимать кнопку Далее.

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

Результат выполненной настройки в центральной базе.

Настройка периферийной базы

После настройки центральной базы необходимо настроить периферийную базу. Для этого добавьте созданную периферийную базу в список задач 1С. PDF При открытии периферийной базы будет автоматически открыто окно настройки синхронизации.

Настройка периферийной базы РИБ выполняется по этапам:

• настройка параметров подключения; PDF
• настройка правил отправки и получения данных.

Настройка выполняется Мастером настройки автоматически. Для настройки Сценария синхронизации нажмите кнопку Добавить и все правила будут созданы по умолчанию. PDF

Следуя шагам Мастера, завершите настройку.

Результат настройки периферийной базы.

После завершения настройки в периферийной базе проверьте наличие перенесенных данных из центральной базы:

• настройки программы;
• справочники;
• документы;

Все данные должны присутствовать. Пример перенесенных поступлений. PDF

Обмен в РИБ

Для обмена периферийной базы с центральной нажмите кнопку Синхронизировать: раздел Администрирование — Настройки программы — Синхронизация данных — ссылка Настройки синхронизации данных.

Будет выполнен обмен с центральной базой.

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

Аналогичные правила для центральной базы.

Перейдите по ссылке Настройка синхронизации данных: раздел Администрирование — Настройки программы — Синхронизация данных — ссылка Настройки синхронизации данных. Нажмите кнопку Синхронизировать. Будет выполнен обмен с периферийной базой.

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

Причины возникновения ошибки

Если в момент обновления конфигурации база «падает» из-за отключения электропитания или медленно работает канал обмена, конфигурация главного узла успевает измениться. а периферийного — нет.

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

• новое обновление центральной конфигурации до получения ответа о предыдущем обновлении периферийной конфигурации;
• динамическое обновление центральной конфигурации;
• отключение электропитания компьютера в момент обновления;
• и т.д.

Обновление конфигурации центральной базы

В том случае, если периферийная база изменения получила, но еще не применила, а в центральной базе в этот промежуток вносятся изменения еще раз и снова инициируют обмен, то возникает конфликт.

Центральная база ожидает увидеть в периферийном узле предыдущие изменения и попытается обновить ее на новые, а по факту конфигурация периферийной базы еще не обновлена.

Динамическое обновление

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

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

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

Это предотвращает в большинстве случаев появление ошибки рассогласования конфигураций центральной и периферийных баз.

Но если по каким-то причинам ошибка все-таки имеет место — проблему нужно решать.

Исправить ошибку можно разными способами. Мы рассмотрим вариант с использование внешней обработки и дадим вам ссылку для скачивания обработки Главный узел на управляемой форме. Если проблема не решится — будут предложены дополнительные варианты решения проблемы.

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

Отключение Главного узла периферийной базы

Данная методика неоднократно помогала нам решить проблему у клиентов при получении ошибки РИБ:

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

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

При попытке обновить конфигурацию вручную команда Обновить конфигурацию недоступна.

Что делать? Рекомендуемая последовательность действий:

• выгрузка конфигурации центральной базы (ЦБ) в файл;
• открепление Главного узла в периферийной базе (ПБ);
• обновление конфигурации в периферийной базе (ПБ);
• закрепление Главного узла в периферийной базе (ПБ).

Выгрузка конфигурации ЦБ в файл

Откройте Конфигуратор ЦБ и выгрузите конфигурацию в файл по кнопке Конфигурация — Сохранить конфигурацию в файл.

Этим файлом мы обновим конфигурацию ПБ после открепления в ней Главного узла обмена.

Открепление Главного узла в ПБ

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

Код этой обработки невероятно прост, всего несколько строчек, и вы можете:

• самостоятельно сделать такую обработку по указанному коду; PDF
• скачать готовый вариант от БухЭксперт8.

Запустите обработку через Главное меню — Файл — Открыть.

Запуск выполняется пользователем с Полными правами или возможностью работать с внешними отчетами и обработками.

Будет открыта форма, указывающая на Главный узел ЦБ, в нашем случае БУХЭКСПЕРТ. Для отключения его нажмите на кнопку Отключить Главный узел.

По окончанию операции выйдет сообщение, что Главный узел отключен.

При отключении Главного узла Конфигуратор ПБ должен быть закрыт.

Обновление конфигурации в ПБ

Откройте конфигуратор ПБ и убедитесь, что блокировка на обновление снята и команда обновить конфигурацию доступна: меню Конфигурация — Поддержка — Обновить конфигурацию. Тем не менее обновить конфигурацию ПБ выгруженным файлом конфигурации ЦБ на актуальных конфигурациях 1С не получится, для этого снимем с поддержки конфигурацию ПБ, а потом вернем ее при загрузке файла конфигурации ЦБ: меню Конфигурация — Поддержка — Настройки поддержки — кнопка Снять с поддержки.

Загрузите файл конфигурации ЦБ: меню Конфигурация — Загрузить конфигурацию из файла.

Примите обновление конфигурации по кнопке F7.

Главный результат операции в сопоставлении редакций ЦБ и ПФ. Они должны быть одинаковыми. Проверить после обновления редакцию ПБ можно по меню Справка — О программе.

Подключение Главного узла в ПБ

Откройте ПБ в пользовательском режиме. На актуальных релизах 1С программа автоматически видит отключенный Главный узел и предлагает его восстановить. Нажимаете кнопку Восстановить.

Программа выполнит автоматическое обновление базы данных.

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

В открывшейся форме в поле Главный узел базы укажите тип данных Полный.

Выберите из списка узлов главный, в нашем случае БУХЭКСПЕРТ, и нажмите кнопку Подключить Главный узел.

При подключении Главного узла Конфигуратор ПБ должен быть закрыт.

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

Корректировка файлов обмена РИБ

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

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

• выгрузка файла обмена из периферийной базы;
• выгрузка файла обмена из центральной базы;
• корректировка файла обмена из ЦБ;
• загрузка скорректированного файла;
• перезапись файла обмена из ПБ;
• проверка исправлений.

Выгрузка файла обмена из периферийной базы

Оставьте рабочим только выполняемое действие настройки Отправка данных, используя кнопку Настроить — Сценарии синхронизации — кнопка Включить/Отключить.

Выполните обмен с центральной базой по кнопке Выполнить сценарий.

Выгрузка файла обмена из центральной базы

Оставьте рабочим только выполняемое действие настройки Отправка данных, используя кнопку Настроить — Сценарии синхронизации — кнопка Включить/Отключить.

Выполните отправку данных из центральной базы по кнопке Выполнить сценарий.

Корректировка файла обмена из ЦБ

В файле обмена из ЦБ замените блок, содержащий информацию об изменениях конфигурации на блок из файла ПБ.

Файлы обмена находятся в папке, которую указали при настройке обмена синхронизации распределенных баз. Всего там находятся два файла:

• Файл выгрузки из периферийной базы: Message_ФЛ_ЦБ.
• Файл выгрузки из центральной базы: Message_ЦБ_ФЛ.

Откройте файл обмена Message_ЦБ_ФЛ, редактором позволяющим редактировать xml-файлы, например, Блокнот.

В файле Message_ЦБ_ФЛ блок <v8de:Config …. </v8de:Config нужно заменить на аналогичный блок файла Message_ФЛ_ЦБ.

Блок файла Message_ЦБ_ФЛ.

Блок файла Message_ФЛ_ЦБ.

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

После замены информации сохраните изменения в файле Message_ЦБ_ФЛ.

Загрузка скорректированного файла

Входим в периферийную базу и загружаем исправленный файл Message_ЦБ_ФЛ. Для этого настраиваем выполняемое действие Получение данных и и загружаем данные по кнопке Выполнить сценарий.

Конфигуратор при получении данных должен быть закрыт.

После этого делаем Отправку данных и переходим в центральную базу.

Проверка обмена в центральной базой

Выполняем Получение данных в центральной базе. Если все хорошо, в отчете отразится информация о том, что данные приняты и отправлены.

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

Да, все отлично. Обмен восстановлен, ошибка исправлена.

Работа с ошибками РИБ относится к разряду профессиональных и Бухэксперт8 рекомендует передавать их для исправления специалистам 1С. При работе с ошибками обязательно копируйте базы данных.

См. также:

• 1C Отчетность: не удалось расшифровать файл
• Этот хост неизвестен 1С: как исправить
• Ошибка при выполнении операции с информационной базой 1С 8.3
• 1С удаление: указанная учетная запись уже существует
• Установка запрещена на основании системной политики 1С 8.3

Если Вы еще не являетесь подписчиком системы БухЭксперт8:

Активировать демо-доступ бесплатно →

или

Оформить подписку на Рубрикатор →

После оформления подписки вам станут доступны все материалы по 1С Бухгалтерия, записи поддерживающих эфиров и вы сможете задавать любые вопросы по 1С.

Подписывайтесь на наши YouTube и Telegram чтобы не пропустить
важные изменения 1С и законодательства

Помогла статья?

Получите еще секретный бонус и полный доступ к справочной системе БухЭксперт8 на 14 дней бесплатно

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

Распределенные базы данных для программ 1С Предприятие использовались предприятиями с удаленными подразделениями, которые не были подключены через интернет. Хотя сейчас большинство пользователей 1С Бухгалтерия работают с общей базой и подключаются к ней через Сеть, все же существует немалое число пользователей программ 1С, которые используют распределенные ИБ. И они время от времени сталкиваются с ошибкой «Конфигурация не соответствует ожидаемой». Рассмотрим, как с ней бороться. 

Почему возникает ошибка

В большинстве случаев сообщение об ошибке выдается в случае, когда выполняется попытка загрузки данных из основной базы в подчиненную. Это говорит о том, что дочерняя ИБ настроена неправильно. Повторное обновление 1С не приведет к исправлению ошибки, она будет появляется все время. Поэтому лучший вариант решить проблему – создать периферийную БД заново. 

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

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

Как исправить ошибку

Для исправления проблемы с распределенной базой данных в 1С Предприятие специалисты по обслуживанию 1С рекомендуют действовать по следующей схеме:

• Очистить кэш программы 1С и выполнить синхронизацию заново. Возможно, ошибка исчезнет уже на этом этапе;
• Завершите работу с ИБ и сделайте ее копию;
• Выгрузите текущую конфигурацию в файл с основной ИБ;
• Отключите основной узел с помощью обработки;
• В режиме конфигурации на подчиненной удаленной базе, с которой не выполняется обмен, нужно снять ее с поддержки;
• Обновить конфигурацию и загрузить файл основной ИБ, который был сделан ранее;
• С помощью обработки снова подключите БД к основному узлу. 

После этого обмен между удаленными базами будет восстановлен.

У вас есть проблемы с программами 1С? Хотите купить 1С Бухгалтерию или заключить договор на обслуживание 1С? Обращайтесь за помощью к специалистам компании «ГК в Приоритете». 

• Permalink

В каких случаях в 1С возникает ошибка “Конфигурация не соответствует ожидаемой”?

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

Как исправить данную ошибку и восстановить обмен в распределенной информационной базе 1С 8?

Действуйте строго по указанным шагам:

• После получения сообщения об ошибке прежде всего выгоните всех пользователей из дочерней базы и заблокируйте ее;
• Сделайте копию или выгрузку дочерней базы;
• Выгрузите конфигурацию(файл с расширением cf) из материнской базы(В режиме конфигуратор Конфигурация -> Сохранить конфигурацию в файл…);
• При помощи обработки “Реанимация подчиненного узла”(скачайте по ссылке) отключите главный узел базы;
• Зайдите в конфигуратор дочерней базы и снимите ее с поддержки(Конфигурация -> Поддержка — >Настройка поддержки… — >Кнопка “Снять с поддержки”);
• Обновите конфигурацию;
• Загрузите конфигурацию выгруженную из материнской базы(Конфигурация -> Загрузить конфигурацию из файла…);
• Обновите конфигурацию;
• Закройте конфигуратор дочерней базы и зайдите в нее в режиме 1С:Предприятие;
• При помощи обработки “Реанимация подчиненного узла” подключите главный узел информационной базы;
• Запустите обмен в дочерней базе(выгрузка должна пройти, а загрузка будет с той же ошибкой);
• Запустите обмен в материнской базе(и загрузка и выгрузка должна пройти без ошибок);
• Запустите обмен в дочерней базе (и загрузка и выгрузка должна пройти без ошибок);
• На этом все.

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

Предистория.

Два дня назад осуществили переход с 8.1 на 8.2 — меняли конфу УПП 1.2… на 1.3.22.1. Соответственно куча отличий от типовой конфигурации, которые накатывали — повлекло за собой кучу ошибок. Два дня, не ночуя, меняем конфигурацию в режиме нон-стоп. Конфигуратор сохраняется раз 15 в час. Следовало ожидать, что при сохранении, конфигурация может вылететь, что собственно и произошло. Такие проблемы, в конфе 8.1 — всегда разрешались выходом пользователей, которые еще работали в базе, но уже не могли повторно войти и монопольным доступом. В нашей же новой конфигурации 8.2 база сказала нам «Я устал. Я ухожуй» ), в общем проблема описана в анонсе.

Что было предпринято из правильного и неправильного. И совет о том что делать первым делом.

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

http://www.forum.mista.ru/topic.php?id=534298

http://devtrainingforum.v8.1c.ru/forum/thread.jsp?id=573910

http://sysadmins.ru/post9322239.html

В общем во всех трех статьях ответ на решение текущий проблемы один — «Восстанавливайте базу из бэкапа».

Не стоит говорить о важности бэкапов их регулярности и прочем. Считаю что в плане нас это было хорошим предупреждением, хотя у нас и был бэкап базы после ее сохранения в конфигурации 1.3 но за их регулярностью и тем что они делаются (а винчестер не чистится и прочее) , за этим мало кто следит. Соответственно простите за «капитана очевидность», но если у вас есть свежий бэкап — первым делом и займитесь восстановлением базы из него, не теряйте драгоценное время, за простой которого руководство вас не поблагодарит. Однако можно попытаться оживить «упавшую» базу, что благодаря моей настырности было и предпринято. Отмечу, что другим программистом также были приняты попытки как то оживить базу 1с-вскими способами, но они были безуспешны. Не знаю всего что он делал, но видел попытки запуска 1С в командном режиме сразу с запуском Тестирования и исправления ИБ, которые собственно ничего не запускали.

Я заострил свое внимание на SQL. Небольшой опыт конфигурирования и администрирования баз и типовой набор sql-команд мне знаком, но изложенный ниже способ итак не потребует никаких глубоких знаний и навыков работы с SQL. Я просто подключил логику — если база «упала» в момент сохранения конфигурации, делаем вывод, что в SQL могла порушиться структура одной таблицы (хотя я не знал до этого что конфигурация в 8 версии лежит в одной сиквель таблице) и эта таблица в которой хранится конфигурация базы. а именном таблица dbo.config. Это в последствии я узнал методом «самотыка» и опять же логики, ибо единственное что нашел это местную разработку, мне не помогшую но довольно полезную на будущее, а именно //infostart.ru/public/61114/ Спасибо автору от учетки моего коллеги, с помощью которого я ее скачал. Итак перехожу к самому важному — попытки(!) восстановления базы ибо гарантий никаких я вам, к сожалению, дать не могу и тому есть ряд предустановок, которых у вас может и не быть или как говорится — это не ваш случай…

Требования и непосредственно само восстановление базы.

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

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

Исходные данные — SQL база 1С 8.2, конфигурация УПП 1.3.22.1 (полагаю описанный способ подойдет для любой эскюэльной базы 8.2). SQL сервер 2005. Ошибка описанная в анонсе и ошибка возникшая в момент сохранения конфигурации! Самое важное и обязательное требование!!! Копия SQL базы с ТАКОЙ  ЖЕ КОНФИГУРАЦИЕЙ(!) У нас настроен авто-обмен с другой базой и конфигурации их совпадают. Кроме этого, так как нас трое программистов 1С — у каждого есть выгруженный и относительно свежий файл конфы. По факту подойдет любая база, неважно с какими данными, главное чтобы конфигурация в ней соответствовала структуре метаданных базы. Отмечу тот факт, что конфигурация даже немного отличалась от той, с которой база вылетела. Самое основное, на мой взгляд, требование, чтобы отличия в конфигурации не затрагивали метаданные. Не стоит забывать тот факт, что если конфигурация отличается, то в итоге вы получите рабочую базу но с конфигурацией из вашей копии.

Сам процесс восстановления не займет у вас много времени — буквально пару минут, но крайне рекомендую предварительно сделать бэкап даже «упавшей» базы, а он может занять время. Например у вас будет возможность восстановить базу откатом из log-файла (который у нас к сожалению в суматохе восстановления «грохнули») или еще какой способ. Итак, напомню что где то должна быть SQL база неважно какими данными но с такой же конфигурацией. Если у вас конфигурация представляет из себя «нетроганную» типовую  (что подразумевает, что данная проблема возникла в процессе наката новой типовой конфигурации) — можете создать новую пустую базу и залить туда типовую конфу, которая у вас была до этого. В случае, если конфигурация, которую вы нашли, не такая уж свежая — подумайте и примите решение, возможно те отличия с копией конфигуратора, которые вы будете вынуждены повторить в вашей базе, займут много больше времени и ресурсов, нежели потеря информации самой базы данных 1С. Своеобразная палка о двух концах ) Итак…

1. Делаем бэкап рухнувшей базы средствами SQL.

2. Очищаем таблицу dbo.config нашей базы в которой лежит наша порушенная конфа. Это можно сделать из SQL- Profiler, к примеру запустив в нем команду:

Use Base2009

go

Delete From [DBO].[Config]

go

где Base2009 имя рухнувшей базы.

Примечание: где-то в сети читал непроверенную инфу, что иногда помогает очистка таблицы dbo.ConfigSave, в которой, якобы, лежит накатываемая конфа. В нашей базе она оказалась пустая, поэтому чистить пустую таблицу, понятно не стал. Возможно — можно как-нибудь обмануть и оживить базу 1С, используя данную таблицу но, не зная механизм работы 1С с этой таблицей, ничего не буду говорить в плане действий, применительно к ней.

3. Копируем таблицу из базы с целой конфигурацией, в нашу порушенную базу. В моём случае обе базы были на одном сервере поэтому команда копирования в SQL-Profiler выглядела так.

insert into [base2009].[Dbo].[Config] select * from [BaseCopy].[Dbo].[Config]

go

где base2009 — имя рухнувшей базы, BaseCopy имя базы с копией конфигуратора

4. Запускаем 1С, и в случае успеха — прыгаем, как я от радости, что удалось оживить базу без каких-либо потерь информации.

5. (Капитан очевидность) проверяем отлаживаем и следим за системой создания бэкапов базы и очень ответственно подходим к процессу обновления конфигурации (делаем это не по сети, а желательно на сервере, по возможности сделав предварительно бэкап). Особенно если версия вашей 1С стала 8.2. Насколько я понял из статей в сети и превых двух дней работы с ней, что она более чувствительна и капризна, по сравнению 8.1 с которой таких проблем не было.

5а. Если конфигурация базы с которой вы будете копировать таблицу конфы — все-таки отличается, (не имея при этом отличий в метаданных, о чем я уже говорил), и где-то лежит ваш относительно свежий cf-файл с выгруженной конфой — накатываем его на ожившую базу. В противном случае Вам придется повторить все те отличия, которые были с копией конфигуратора. Так что еще раз хорошо подумайте и проанализируйте — что важнее — ваша работа по изменению конфигурации (и сколько времени вы на это потратите) или работа пользователей базы до момента последнего бэкапа. В моем случае это была работа 2-х программистов в течении 3-х часов против работы порядка 100 пользователей в течении 1.5 дней, так что выбор был очевиден.

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

З.Ы.Ы. Это моя первая публикация тут т.к. трусь на других 1С форумах, но нахожу этот ресурс одним из самых полезных в плане выложенных разработок и публикаций, поэтому не судите строго за много ЕСЛИ в данной публикации). Буду очень рад, если реально помог кому-нибудь с восстановлением порушенной базы ибо страшнее этого только ядерная война )

З.Ы.Ы.Ы. Спустя 3 недели проблема повторилась ) На этот раз на решение было потрачены какие-то секунды (если не учитывать время создания бэкапа), и даже пользователей не пришлось выгонять.

_____________________________________________________________________________________________________________

Сегодня прибежал коллега. Та же самая беда. Только база тестовая а не рабочая и сама база ему поскольку постольку — а вот конфигуратор ему важен. Неделю он краптел над ним ни разу не выгрузив в cf файл и не накатив изменения в рабочую базу. Ну что ж — почему бы не поковырятся уже с таблицей?! На этот раз все еще проще. Открываю SQL Managment Studio. Формирую запрос по таблице на поля с текущей датой изменения и временем когда у него вылетела база — результат дает 2 записи. Первая — Поле FileName  = «commit» Ну что же — грохнуть эту запись — и у меня все получилось! Конфигуратор ожил и база опять работает. Что же нужно сделать?! 

Итак в открытом окне SQL Managment Studio ищем нашу базу — открываем Таблицы, ищем в конце списка таблицу с конфой dbo.config на таблице — правую кнопку — Открыть таблицу. Далее в правом окне спускаемся в самой таблице вниз по алфавиту на поле где FileName  = «commit». Встаем на эту запись — правую кнопку мыши — Удалить. В общем удаляем  запись с двоичным файлом. Далее пробуем зайти в конфу. Ошибка та же самая первая появляется. Наверно не получилось?Ё  Нажимаем Ок. И тут, прежде чем выдать как ранее 2-е сообщение о невозможности сохранить —  компьютер задумался. Спустя секунд 30 — О ЧУДО! Конфигуратор открылся. Пробуем сохранить конфигуратор (предварительно сохранив cf файл). Конфигуратор сохраняется. Таким образом и волки сыты и овцы целы. Не уверен насчет полной работоспосбности базы после таких измывательств — так что посоветую сделать реструтуризацию и пересчет итогов уже потом вечером (предварительно конечно же сделав архив). Удачного востановления и положительных эмоций )