РИБ ошибка при обмене |
Я |
28.02.13 — 14:56
Обновил Центральную базу, после чего выполнил обмен с Подчиненной, и обновил ее. Дальше стал выгружать данные из Подчиненной, они записались в файл, а вот при загрузке в Центральную вышло сообщение «Ошибка при чтении изменений при обмене РИБ: Ошибка при вызове метода контекста (ПрочитатьИзменения): Изменения конфигурации не могут быть получены из подчиненного узла распределенной ИБ».
Подчиненная база точно обновилась, сделал сравнение конфигураций, они одинаковы. В чем может быть проблема, и куда копать?
Конфа БП+БИТФинанс.
1 — 28.02.13 — 15:00
F7 нажимал в конфигураторе?
2 — 28.02.13 — 15:02
Да, нажимал. В подчиненной все обновилось.
3 — 28.02.13 — 15:03
еще раз попробуй, может файл старый, или кто без тебя ЦБ правит втихую
4 — 28.02.13 — 15:05
Повторно тоже попробовал, та же беда.
5 — 28.02.13 — 15:07
версии платформ центра и периферии совпадают?
6 — 28.02.13 — 15:08
(подсказака) Может быть ты снял «признак» подчиненного узла и забыл его восстановить?
7 — 28.02.13 — 15:08
Еще раз по пунктам, так делаешь:
1. Изменили ЦБ, получили файл ЦБ_РИБ
2. Обмен на РИБ файлом из п.1.
3. Применение изменений конфигурации.
4. !!! Самое главное, аналогично п.2: Обмен на РИБ файлом из п.1.
5. А вот только теперь файл РИБ_ЦБ обратно в центр передаем
8 — 28.02.13 — 15:11
(7) даже если пропустить п. 4 ошибки «Изменения конфигурации не могут быть получены из подчиненного узла распределенной ИБ» быть не должно..
9 — 28.02.13 — 15:13
(8) да нет, п.4. как раз самый главный,
хотя есть еще вариант что кто-то РИБ конфиг правил
10 — 28.02.13 — 15:16
(7) Делал без п.4. Сейчас буду пробовать. (9) РИБ конфиг никто не правил.
11 — 28.02.13 — 15:17
(5) Версии совпадаю. И сравнением конфигураций различий не нашел.
12 — 28.02.13 — 15:25
(9) Если бы не был выполнен пункт 3 или 4, то ошибка была бы такая «Ошибка при вызове метода контекста (ПрочитатьИзменения): Данные принимаются от узла, для которого зарегистрированы изменения конфигурации.»
А такую ошибку как у ТС что то в первый раз вижу..
13 — 28.02.13 — 15:31
(12) Два раза все переделывал. Что можно еще попробовать сделать?
14 — 28.02.13 — 15:35
ну хз, попробуй изменить главную еще раз и еще раз обновить дочернюю)
15 — 28.02.13 — 15:45
Файл сообщения обмена из подчиненного узла посмотри «напрямую».
Если там действительно есть изменение конфигурации (что мало вероятно) — забыли признак подчиненого узла восстановить.
Если нет там никакого изменения конфигурации — то посмотри внимательно на «идентификаторы» конфигурациий в заголовке.
PS: «Демоническое рассогласование конфигураций». Сам придумал термин для демонического обновленияи. И, увы, уже давно.
16 — 28.02.13 — 15:53
Есть обработка в инете, которая снимает с подчиненной признак, что она подчиненная,после этого загружаешь (не сравнить и объединить) конфу из главного узла, а потом той-же обработкой делаешь ее обратно подчиненной. Была такая фигня несколько раз
17 — 28.02.13 — 16:44
(12) а ну да, согласен, невнимательно текст ошибки почитал.
хотя п.4 все равно обязателен )
18 — 28.02.13 — 19:39
вот прям щас такая же беда случилась. По удаленке настраивал РИБ. Обмен через каталог. А в качестве такого — Dropbox.
Обновил головную, выгрузил файл на 27мб, загрузил в периферийную, нажал F7. И запустил повторно обмен в периферийной. И она выгрузила вместо 1кб «все ок» — файл 27мб «изменения конфы».
Основная конечно такой файл не съела и выдала вышеописанную ошибку. После чего основная выдала снова файл 27мб. Я его снова скормил периферийной- и о чудо! Она ответила 1кб «ок», в конфигураторе F7 не просит.
В общем мысль такая: если после обновления периферийной ей не дали снова «тот самый первый файл» 27мб — она гонит и выгружает «изменения в конфе» обратно.
19 — 28.02.13 — 19:41
доп. пояснение: настраивал авт. обмен — запуск при появлении файла обмена. При этом после чтения оного 1с:Бухгалтерия удаляет его. Чего не случается при ручном обмене.
20 — 01.03.13 — 06:30
(16) Победил =) Снял признак подчиненной, загрузил cf-ник, и обмен прошел.
Всем спасибо за советы.
21 — 01.03.13 — 08:48
filterhouse, я рад за вас
PS: хотелось бы один момент уточнить. После обновления конфигурации подчиненного узла вызывали сеанс «1С:Предприятия» для запуска обработок обновления или минуя это делали обмен данными?
filterhouse
22 — 01.03.13 — 16:28
(21) Не совсем понял что вы имели ввиду: «вызывали сеанс «1С:Предприятия» для запуска обработок обновления», может уже под конец пятницы голова не соображает.
Снял признак подчиненной, загрузил cf-ник, в Предприятии обработкой вернул на место признак подчиненной, и произвел обмен.
Наверное я не ответил на ваш вопрос =)
Здравствуйте, уважаемые читатели нашего блога SoftMaker.kz! Сегодня поговорим об исправлении двух ошибок, которые могут возникнуть при обмене в распределенной информационной базе (РИБ). Такие ошибки могут возникнуть, если вы изменили конфигурацию вашей базы и пытаетесь передать эти изменения из центральной базы в периферийную. Например, способом, который был описан здесь. Давайте приступим!
Вот такие сообщения могут появиться при попытки сделать обмен при помощи РИБ:
«Данные принимаются от узла, для которого зарегистрированы изменения конфигурации. Необходимо произвести перенос изменений конфигурации в узел.»
«Конфигурация узла распределенной ИБ не соответствует ожидаемой!»
Давайте рассмотрим шаги, которые помогут исправить ситуацию. Перед тем как начнем, сделаем резервные копии наших информационных баз!!!
-
- Возьмем файл конфигурации с обновлением, откроем центральную базу в Конфигураторе и загрузим его (Конфигурация-Загрузить конфигурацию из файла…). Сохраним ИБ (F7).
- Изменим настройку поддержки (Конфигурация-Поддержка-Настройка поддержки…). В диалоге выделим в таблице ячейку на пересечении первой строки и второй колонки. Затем двойным нажатием вызовем диалог «Настройка правил поддержки». В нем поставим флаг «Установить для подчиненных объектов» и нажмем кнопку «ОК». Закроем диалог настройки поддержки, нажав кнопку «Закрыть». Сохранить ИБ (F7). Закроем Конфигуратор.
- Зайдем в режим 1С:Предприятие и сделаем выгрузку в файл для периферийной базы:
- Операции-Планы обмена-Выбрать наш план обмена (например, «По складу»).
- Выделим план обмена в списке, затем Правой кнопкой вызвать контекстное меню и выбрем пункт «Записать изменения…».
- В диалоге укажем путь и имя файла обмена. Нажмем кнопку «ОК».
- Теперь займемся периферийной ИБ. Откроем ее в монопольном режиме, чтобы никого из пользователей не было, а также закроем Конфигуратор. Теперь необходимо запомнить узел, который является главным для текущей базы. Откроем Операции-Планы обмена-Выбрать ваш план обмена (например, «По складу»). В списке планов обмена главным узлом является элемент с желтой пиктограммой. Эта информация пригодится нам в седьмом пункте. Откроем обработку УстановкаГлавногоУзлаБД.epf и нажмем кнопку «Отменить назначение главного узла».
- Теперь откроем периферийную ИБ в Конфигураторе и загрузим тот же файл конфигурации, который мы загружали на первом шаге в центральной базе (Конфигурация-Загрузить конфигурацию из файла…). Сохраним ИБ (F7).
- Изменим настройку поддержки (Конфигурация-Поддержка-Настройка поддержки…). В диалоге выделим в таблице ячейку на пересечении первой строки и второй колонки. Затем двойным нажатием вызовем диалог «Настройка правил поддержки». В нем поставим флаг «Установить для подчиненных объектов» и нажмем кнопку «ОК». Закроем диалог настройки поддержки, нажав кнопку «Закрыть». Сохранить ИБ (F7). Закроем Конфигуратор.
- Теперь опять откроем периферийную ИБ в монопольном режиме 1С:Предприятие, чтобы никого из пользователей не было, а также закроем Конфигуратор. Откроем обработку УстановкаГлавногоУзлаБД.epf и выберем план обмена, который мы хотим установить главным узлом (в четвертом пункте мы запоминали этот узел). Затем нажмем кнопку «Установить главный узел». После этого текущая ИБ снова станет периферийной.
- Теперь в текущей ИБ (периферийной) откроем планы обмена и загрузим файл с обменом из Центральной базы, который мы получили на третьем шаге:
- Операции-Планы обмена-Выбрать наш план обмена (например, «По складу»).
- Выделим план обмена в списке-Правой кнопкой вызовем контекстное меню и выбрать пункт «Прочитать изменения…»
- В диалоге выберем файл обмена. Нажмем кнопку «ОК».
- Если все прошло успешно, то сделаем выгрузку обмена для Центральной базы в текущей ИБ (периферийной):
- Операции-Планы обмена-Выбрать наш план обмена (например, «По складу»).
- Выделим план обмена в списке, затем Правой кнопкой вызвать контекстное меню и выберем пункт «Записать изменения…».
- В диалоге укажем путь и имя файла обмена. Нажмем кнопку «ОК».
- Теперь попробуем загрузить этот файл в Центральной базе, откроем ее в режиме 1С:Предприятие:
- Операции-Планы обмена-Выбрать наш план обмена (например, «По складу»).
- Выделим план обмена в списке-Правой кнопкой вызовем контекстное меню и выбрать пункт «Прочитать изменения…»
- В диалоге выберем файл обмена. Нажмем кнопку «ОК».
Чтобы избежать проблем с рабочими копиями сделайте сначала резервные копии центральной и периферийной баз, а потом попробуйте применить эти шаги.
ПОДПИСКА
Конфигурация узла распределенной ИБ не соответствует ожидаемой. Одна из самых популярных ошибок РИБ. Приведены стандартная методика устранения (уже публиковалась ранее) и расширенная (для сложных случаев).
Для начала привожу список используемых мной сокращений:
- РИБ — распределенная информационная база
- ЦБ — центральная база, корневой узел РИБ
- УБ — удаленная база, БД удаленного узла РИБ
По собственному опыт могу сказать, что сталкивался с двумя причинам возникновения ошибки:
- во время приёма файла сообщения в УБ «упала» база, в связи с чем, видимо, и произошла разсинхронизация между конф. ЦБ и УБ;
- под MSSQL клиент загрузил копию рабочей базы и не выключил в копии регл. задания автообмена, в результате часть сообщений в удаленные узлы формировалась из рабочей БД, а часть из копии, что и привело рассинхронизации конфигураций
Есть также мнение, что к этой ошибке приводит использование механизма динамического обновления базы. Здесь есть сомнения, потому как с одной стороны динамическое обновление никогда не затрагивает структуры БД, а механизмы РИБ всё-таки работают именно со структурой БД, а не с прикладной её частью, тем не менее в РИБ используется механизм формирования цифровой подписи версии конфигурации (в дальнейшем буду называть её для сокращения хэшем), и при изменении прикладной части хэш естественно обязан пересчитаться. Не буду ни отрицать этого, ни утверждать, т.к. если и сталкивался с этой ситуацией, то явных доказательств этого не нашел.
Для исправления использую 2 методики, в зависимости от ситуации.
ПЕРВАЯ МЕТОДИКА
Первая (самая распространенная) неоднократно упоминается и в партнерской конференции, и на прочих интернет-ресурсах связанных с 1С. Применяется в большинстве случаев, когда несмотря на сообщение о расхождених конфигураций, при сравнении вручную выдается, что они идентичны.
Последовательность действий:
- выгружаем из ЦБ cf-файл;
- отвязываем УБ от РИБ (метод УстановитьГлавныйУзел, готовую обработку можно найти в приложении или в других публикациях);
- заменяем конф. УБ на выгруженный в первом шаге cf-файл, для этого пользуемся меню «Загрузить конфигурацию из файла» (а не сравнением-объединением!!!);
- восстанавливем признак РИБ для УБ.
В большинстве случаев этих действий более чем достаточно, что восстановить обмен, но не всегда…
ВТОРАЯ МЕТОДИКА
Применяется в случае, если первая методика не сработала, а выгрузить заново узел не представляется возможным.
Предыстория: у клиента настраивали каскадную РИБ и ошибка возникла в первом уровне каскада (второй уровень всё это время работал безупречно). Разработка конфигурации велась совместно с IT-службой клиента и с момента возникновения ошибки конфигурация ЦБ успела несколько раз поменяться. Вариант с откатом изменений не рассматривался даже в принципе, т.к. потеря части данных и остановка работы нескольких подразделений были совершенно неприемлимы. Первый вариант исправления ошибки каких-либо ощутимых результатов не дал. В связи со чем пришлось искать другие пути решения.
Пришла мысль попробовать подменить хэши файлов конфигураций непосредственно в XML-файлах обмена. Описание структуры файла обмена из книги «Профессиональная разработка в системе 1С:Предприятие 8» дало слабое представление о формировании цифровых подписей конфигураций и изменений в них, но определило направление поиска: значения Digest1 и Digest2. Всё остальное выяснял чисто эмпирическим путём (то бишь методом проб и ошибок), но закономерность установить таки получилось.
Тестовые эксперименты прошли удачно. На рабочих базах тоже всё прошло благополучно.
Итак, последовательность действий:
- выполняем действия 1 — 4 первой методики;
- выгружаем из УБ файл обмена, но не загружаем его в ЦБ;
- выгружаем из ЦБ файл обмена, но не загружаем его в УБ;
- в файле обмена из ЦБ заменяем блок, содержащий информацию об изменениях конфигурации и хэши (Digest1 и Digest2), на блок хэшей из файла УБ (пример см. ниже)
- производим загрузку файла из 4-го пункта в УБ;
- обязательно перезаписываем файл обмена из УБ (2-й пункт)! этот файл не должен быть загружен при обмене в ЦБ!
- для проверки делаем несколько последовательных обменов.
Если при обмене используется сжатие данных, то либо отключаем сжатие, либо сначала распаковываем файл, меняем, потом запаковываем обратно и отправляем.
Блок файла обмена из ЦБ
<v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">
<v8de:Version>106.0</v8de:Version>
...здесь идут блоки описания изменений конфигурации...
<v8de:Digest1>1cf680807e97a5dc0d1ed7f901b07392</v8de:Digest1>
<v8de:Digest2>038211651cf680807e97a5dc0d1ed7f9</v8de:Digest2>
</v8de:Config>
нужно заменить на блок файла обмена из УБ (обратите внимание Digest1 у файла из УБ всегда равен «00000000000000000000000000000000»!!!)
<v8de:Config xmlns:v8md="http://v8.1c.ru/metadata/2005/08">
<v8de:Version>106.0</v8de:Version>
<v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
<v8de:Digest2>11651cf680807e97a5dc0d1ed7f901b0</v8de:Digest2>
</v8de:Config>
Перечисленные действия необходимо выполнять с предельной осторожностью, некорректная последовательность чревата полной неработоспособностью РИБ. Поэтому перед этими действиям создание резервных копий ОБЯЗАТЕЛЬНО!
В остальном могу только пожелать удачи!
Обработка ошибок, возникающих при обмене данными в распределенной информационной базе
При организации обмена данными в рамках распределенной информационной базы (РИБ) могут возникать различные ситуации, приводящие к сообщениям об ошибках. Файл обмена данных является текстовым документом в формате XML. Многие ошибки при работе с файлом обмена возникают во время чтения или записи данных XML
Когда у меня возникает ошибка при обмене данных я сперва обращаюсь к статье http://its.1c.ru/db/metod8dev#content:2265:hdoc в поисках пути решения. В этой статье рассматриваются те ошибки, которые так или иначе имеют отношение к обмену данными в рамках распределенной информационной базы . В статье показан список сообщений об ошибке и возможные пути исправления ошибки. Если возможные пути решения возникшей ошибки в этой статье недостаточны, то я рекомендую искать в форумах по описанию сообщения об ошибке. Например, одна из самых распространенных ошибок при РИБ – Конфигурация узла распределенной ИБ не соответствует ожидаемой!. Возможные пути решения к этой ошибки также описаны в статье http://infostart.ru/public/65456/