Ошибки динамического обновления (или другие глюки платформы) могут быть причинами ошибок обмена распределенных информационных баз:
"Данные принимаются от узла, для которого зарегистрированы изменения конфигурации"
"Конфигурация узла распределенной ИБ не соответствует ожидаемой"
Как восстановить обмен?
Но начнем не с воостановления, а с возможности провести о
бмен "вручную", что бывает важно в течении дня, потому что, как всегда, всё должно работать "еще вчера":) Сделать это можно с помощью замечательных обработок, которые я не пом
ню где скачал(авторы, откликнитесь — оставлю ссылки на ваш ресурс, а с моего, если нужно — удалю
). Обработки дают возможность выгрузить только зарегистрированные изменения данных в базе(по указанному плану обмена для определенного узла!) в XML без выгрузки изменений конфигурации и, если объекты конфигурации не сильно видоизменились, то есть очень большие шансы на загрузку этих данных. Обрабокти эти можно скачть по ссылке в конце статьи.
Что касается восстановления. Есть более простые способы, включающие не все пункты приведенного ниже списка, но они не всегда помогают, как например было в одном из моих случаев. Поэтому привожу тот способ, который помог мне, он обходит возможные проблемы более комплексно. Далее по шагам.
Делать указанные шаги желательно тогда, когда в базе не будет работающих пользователей. Если это невозможно, то Вам придеться "допилить" метод под себя, а следовательно нужно сначала понять его логику.
1. Сделать резервные копии везде.
2. Для клиент-серверов: отключить базы через "администрирование сервера" и сразу подключить с установкой блокировки регламентных заданий(таким образом сбросится кэш сервера). После этого не забыть перекинуть в новый каталог журнал регистрации.
3. На всех используемых для восстановления компах удалить базу в списке баз стартера 1С и создать поновой(очистится кеш пользователя)
4. В конфигураторе(в центральной базе) добавить новую константу сохранить изменения конфы.
5. Очистить все каталоги обмена.
6. Сделать выгрузки во все филиалы(пока только выгрузки).
7. Попробовать загрузить(только загрузить) полученные данные во все филиалы. Естественно принять изменения конфы.
Если везде все хорошо, идем далее, если все плохо — думаем, может быть поможет выгрузка.cf из центральной базы и её ЗАГРУЗКА в филиал(не сравнение-объединение). В подчиненном узле следует отвязать базу от РИБ (поможет в этом обработка — скачать по ссылке ниже). Статья на эту тему есть на infostart.ru.
8. Отменяем регистрацию изменений для филиалов в ЦБ(ведь все изменения мы уже везде получили). Важно сделать на этом этапе, чтобы накопившиеся изменения из разных филиалов попали в другие филиалы. (скачать обработку для отвязки-привязки по ссылке ниже).
9. Делаем загрузку в ЦБ и если все хорошо, то делаем загрузку-выгрузку с каждым филиалом несколько раз для закрепления результата.
10. Всё.
Можно включить выполнение регламентных заданий у клиент-серверных баз.
Для профилактики проблем, вызывающиех эту ошибку, рекомендуется не делать динамическое обновление(как минимум несколько раз подряд — до загрузки изменений в филиалы), а также желательно в настройках обмена поставить галочку"выгружать данные только при успешной загрузке".
Здравствуйте, уважаемые читатели нашего блога сайт! Сегодня поговорим об
исправлении двух ошибок
, которые могут возникнуть при обмене в в распределенной информационной базе (РИБ). Такие ошибки могут возникнуть, если вы изменили конфигурацию вашей базы и пытаетесь передать эти изменения из центральной базы в периферийную. Например, способом, который был описан . Давайте приступим!
Вот такие сообщения могут появиться при попытки сделать обмен при помощи РИБ:
«Данные принимаются от узла, для которого
зарегистрированы изменения конфигурации.
Необходимо произвести перенос изменений
конфигурации в узел.»
«Конфигурация узла распределенной ИБ
не соответствует ожидаемой!»
Давайте рассмотрим шаги, которые помогут исправить ситуацию. Перед тем как начнем, сделаем наших информационных баз!!!
- Возьмем файл конфигурации с обновлением, откроем центральную базу в Конфигураторе и загрузим его (Конфигурация-Загрузить конфигурацию из файла…). Сохраним ИБ (F7).
- Зайдем в и сделаем выгрузку в файл для периферийной базы:
- Выделим план обмена в списке, затем Правой кнопкой вызвать контекстное меню и выбрем пункт «Записать изменения…».
- Теперь займемся периферийной ИБ. Откроем ее в монопольном режиме, чтобы никого из пользователей не было, а также закроем Конфигуратор. Теперь необходимо запомнить узел, который является главным для текущей базы. Откроем Операции-Планы обмена-Выбрать ваш план обмена (например, «По складу»). В списке планов обмена главным узлом является элемент с желтой пиктограммой. Эта информация пригодится нам в седьмом пункте. Откроем обработку и нажмем кнопку «Отменить назначение главного узла».
- Теперь откроем периферийную ИБ в Конфигураторе и загрузим тот же файл конфигурации, который мы загружали на первом шаге в центральной базе (Конфигурация-Загрузить конфигурацию из файла…). Сохраним ИБ (F7).
- Изменим настройку поддержки (Конфигурация-Поддержка-Настройка поддержки…). В диалоге выделим в таблице ячейку на пересечении первой строки и второй колонки. Затем двойным нажатием вызовем диалог «Настройка правил поддержки». В нем поставим флаг «Установить для подчиненных объектов» и нажмем кнопку «ОК». Закроем диалог настройки поддержки, нажав кнопку «Закрыть». Сохранить ИБ (F7). Закроем Конфигуратор.
- Теперь опять откроем периферийную ИБ в монопольном режиме 1С:Предприятие, чтобы никого из пользователей не было, а также закроем Конфигуратор. Откроем обработку УстановкаГлавногоУзлаБД.epf и выберем план обмена, который мы хотим установить главным узлом (в четвертом пункте мы запоминали этот узел). Затем нажмем кнопку «Установить главный узел». После этого текущая ИБ снова станет периферийной.
- Теперь в текущей ИБ (периферийной) откроем планы обмена и загрузим файл с обменом из Центральной базы, который мы получили на третьем шаге:
- Операции-Планы обмена-Выбрать наш план обмена (например, «По складу»).
- Если все прошло успешно, то сделаем выгрузку обмена для Центральной базы в текущей ИБ (периферийной):
- Операции-Планы обмена-Выбрать наш план обмена (например, «По складу»).
- Выделим план обмена в списке, затем Правой кнопкой вызвать контекстное меню и выберем пункт «Записать изменения…».
- В диалоге укажем путь и имя файла обмена. Нажмем кнопку «ОК».
- Теперь попробуем загрузить этот файл в Центральной базе, откроем ее в режиме 1С:Предприятие:
- Операции-Планы обмена-Выбрать наш план обмена (например, «По складу»).
- Выделим план обмена в списке-Правой кнопкой вызовем контекстное меню и выбрать пункт «Прочитать изменения…»
- В диалоге выберем файл обмена. Нажмем кнопку «ОК».
Чтобы избежать проблем с рабочими копиями сделайте сначала
Для начала привожу список используемых мной сокращений:
- РИБ - распределенная информационная база
- ЦБ - центральная база, корневой узел РИБ
- УБ - удаленная база, БД удаленного узла РИБ
По собственному опыт могу сказать, что сталкивался с двумя причинам возникновения ошибки:
- во время приёма файла сообщения в УБ "упала" база, в связи с чем, видимо, и произошла разсинхронизация между конф. ЦБ и УБ;
- под MSSQL клиент загрузил копию рабочей базы и не выключил в копии регл. задания автообмена, в результате часть сообщений в удаленные узлы формировалась из рабочей БД, а часть из копии, что и привело рассинхронизации конфигураций
Есть также мнение, что к этой ошибке приводит использование механизма динамического обновления базы. Здесь есть сомнения, потому как с одной стороны динамическое обновление никогда не затрагивает структуры БД, а механизмы РИБ всё-таки работают именно со структурой БД, а не с прикладной её частью, тем не менее в РИБ используется механизм формирования цифровой подписи версии конфигурации (в дальнейшем буду называть её для сокращения хэшем), и при изменении прикладной части хэш естественно обязан пересчитаться. Не буду ни отрицать этого, ни утверждать, т.к. если и сталкивался с этой ситуацией, то явных доказательств этого не нашел.
Для исправления использую 2 методики, в зависимости от ситуации.
ПЕРВАЯ МЕТОДИКА
Первая (самая распространенная) неоднократно упоминается и в партнерской конференции, и на прочих интернет-ресурсах связанных с 1С. Применяется в большинстве случаев, когда несмотря на сообщение о расхождених конфигураций, при сравнении вручную выдается, что они идентичны.
Последовательность действий:
- выгружаем из ЦБ cf-файл;
- отвязываем УБ от РИБ (метод УстановитьГлавныйУзел, готовую обработку можно найти в приложении или в других публикациях);
- заменяем конф. УБ на выгруженный в первом шаге cf-файл, для этого пользуемся меню "Загрузить конфигурацию из файла" (а не сравнением-объединением!!!);
- восстанавливем признак РИБ для УБ.
В большинстве случаев этих действий более чем достаточно, что восстановить обмен, но не всегда...
ВТОРАЯ МЕТОДИКА
Применяется в случае, если первая методика не сработала, а выгрузить заново узел не представляется возможным.
Предыстория: у клиента настраивали каскадную РИБ и ошибка возникла в первом уровне каскада (второй уровень всё это время работал безупречно). Разработка конфигурации велась совместно с IT-службой клиента и с момента возникновения ошибки конфигурация ЦБ успела несколько раз поменяться. Вариант с откатом изменений не рассматривался даже в принципе, т.к. потеря части данных и остановка работы нескольких подразделений были совершенно неприемлимы. Первый вариант исправления ошибки каких-либо ощутимых результатов не дал. В связи со чем пришлось искать другие пути решения.
Пришла мысль попробовать подменить хэши файлов конфигураций непосредственно в XML-файлах обмена. Описание структуры файла обмена из книги "Профессиональная разработка в системе 1С:Предприятие 8" дало слабое представление о формировании цифровых подписей конфигураций и изменений в них, но определило направление поиска: значения Digest1 и Digest2. Всё остальное выяснял чисто эмпирическим путём (то бишь методом проб и ошибок), но закономерность установить таки получилось.
Тестовые эксперименты прошли удачно. На рабочих базах тоже всё прошло благополучно.
Итак, последовательность действий:
- выполняем действия 1 - 4 первой методики;
- выгружаем из УБ файл обмена, но не загружаем его в ЦБ;
- выгружаем из ЦБ файл обмена, но не загружаем его в УБ;
- в файле обмена из ЦБ заменяем блок, содержащий информацию об изменениях конфигурации и хэши (Digest1 и Digest2), на блок хэшей из файла УБ (пример см. ниже)
- производим загрузку файла из 4-го пункта в УБ;
- обязательно перезаписываем файл обмена из УБ (2-й пункт)! этот файл не должен быть загружен при обмене в ЦБ!
- для проверки делаем несколько последовательных обменов.
Если при обмене используется сжатие данных, то либо отключаем сжатие, либо сначала распаковываем файл, меняем, потом запаковываем обратно и отправляем.
Блок файла обмена из ЦБ
...здесь идут блоки описания изменений конфигурации...
нужно заменить на блок файла обмена из УБ (обратите внимание Digest1 у файла из УБ всегда равен "00000000000000000000000000000000"!!!)
Перечисленные действия необходимо выполнять с предельной осторожностью, некорректная последовательность чревата полной неработоспособностью РИБ. Поэтому перед этими действиям создание резервных копий ОБЯЗАТЕЛЬНО!
В остальном могу только пожелать удачи!
Для начала список используемых сокращений:
- РИБ - распределенная информационная база
- ЦБ - центральная база, корневой узел РИБ
- УБ - удаленная база, БД удаленного узла РИБ
По собственному опыт могу сказать, что сталкивался с двумя причинам возникновения ошибки:
- во время приёма файла сообщения в УБ "упала" база, в связи с чем, видимо, и произошла разсинхронизация между конф. ЦБ и УБ;
- под MSSQL клиент загрузил копию рабочей базы и не выключил в копии регл. задания автообмена, в результате часть сообщений в удаленные узлы формировалась из рабочей БД, а часть из копии, что и привело рассинхронизации конфигураций
Есть также мнение, что к этой ошибке приводит использование механизма динамического обновления базы. Здесь есть сомнения, потому как с одной стороны динамическое обновление никогда не затрагивает структуры БД, а механизмы РИБ всё-таки работают именно со структурой БД, а не с прикладной её частью, тем не менее в РИБ используется механизм формирования цифровой подписи версии конфигурации (в дальнейшем буду называть её для сокращения хэшем), и при изменении прикладной части хэш естественно обязан пересчитаться. Не буду ни отрицать этого, ни утверждать, т.к. если и сталкивался с этой ситуацией, то явных доказательств этого не нашел.
Для исправления использую 2 методики, в зависимости от ситуации.
ПЕРВАЯ МЕТОДИКА
Первая (самая распространенная) неоднократно упоминается и в партнерской конференции, и на прочих интернет-ресурсах связанных с 1С. Применяется в большинстве случаев, когда несмотря на сообщение о расхождених конфигураций, при сравнении вручную выдается, что они идентичны.
Последовательность действий:
- выгружаем из ЦБ cf-файл;
- отвязываем УБ от РИБ (метод УстановитьГлавныйУзел, готовую обработку можно найти в приложении или в других публикациях);
- заменяем конф. УБ на выгруженный в первом шаге cf-файл, для этого пользуемся меню "Загрузить конфигурацию из файла" (а не сравнением-объединением!!!);
- восстанавливем признак РИБ для УБ.
В большинстве случаев этих действий более чем достаточно, что восстановить обмен, но не всегда...
ВТОРАЯ МЕТОДИКА
Применяется в случае, если первая методика не сработала, а выгрузить заново узел не представляется возможным.
Предыстория: у клиента настраивали каскадную РИБ и ошибка возникла в первом уровне каскада (второй уровень всё это время работал безупречно). Разработка конфигурации велась совместно с IT-службой клиента и с момента возникновения ошибки конфигурация ЦБ успела несколько раз поменяться. Вариант с откатом изменений не рассматривался даже в принципе, т.к. потеря части данных и остановка работы нескольких подразделений были совершенно неприемлимы. Первый вариант исправления ошибки каких-либо ощутимых результатов не дал. В связи со чем пришлось искать другие пути решения.
Пришла мысль попробовать подменить хэши файлов конфигураций непосредственно в XML-файлах обмена. Описание структуры файла обмена из книги "Профессиональная разработка в системе 1С:Предприятие 8" дало слабое представление о формировании цифровых подписей конфигураций и изменений в них, но определило направление поиска: значения Digest1 и Digest2. Всё остальное выяснял чисто эмпирическим путём (то бишь методом проб и ошибок), но закономерность установить таки получилось.
Тестовые эксперименты прошли удачно. На рабочих базах тоже всё прошло благополучно.
Итак, последовательность действий:
- выполняем действия 1 - 4 первой методики;
- выгружаем из УБ файл обмена, но не загружаем его в ЦБ;
- выгружаем из ЦБ файл обмена, но не загружаем его в УБ;
- в файле обмена из ЦБ заменяем блок, содержащий информацию об изменениях конфигурации и хэши (Digest1 и Digest2), на блок хэшей из файла УБ (пример см. ниже)
- производим загрузку файла из 4-го пункта в УБ;
- обязательно перезаписываем файл обмена из УБ (2-й пункт)! этот файл не должен быть загружен при обмене в ЦБ!
- для проверки делаем несколько последовательных обменов.
Если при обмене используется сжатие данных, то либо отключаем сжатие, либо сначала распаковываем файл, меняем, потом запаковываем обратно и отправляем.
Блок файла обмена из ЦБ
...здесь идут блоки описания изменений конфигурации...
нужно заменить на блок файла обмена из УБ (обратите внимание Digest1 у файла из УБ всегда равен "00000000000000000000000000000000"!!!)
Перечисленные действия необходимо выполнять с предельной осторожностью, некорректная последовательность чревата полной неработоспособностью РИБ. Поэтому перед этими действиям создание резервных копий ОБЯЗАТЕЛЬНО!
