Конфігурація розподіленої ІБ не відповідає очікуваної. Для профілактики проблем, визивающіех цю помилку, рекомендується не робити динамічне оновлення (як мінімум кілька разів поспіль - до завантаження змін в філії), а також бажано в налаштуваннях

Привіт, шановні читачі нашого блогу сайт! Сьогодні поговоримо про
виправленні двох помилок, Які можуть виникнути при обміні в в розподіленій інформаційній базі (РИБ). Такі помилки можуть виникнути, якщо ви змінили конфігурацію вашої бази і намагаєтеся передати ці зміни з центральної бази в периферійну. Наприклад, способом, який був описаний. Давайте приступимо!

Ось такі повідомлення можуть з'явитися при спроби зробити обмін за допомогою РИБ:

«Дані приймаються від вузла, для якого
зареєстровані зміни конфігурації.
Необхідно зробити перенесення змін
конфігурації в вузол. »


«Конфігурація вузла розподіленої ІБ
не відповідає очікуваної! »

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

1. Візьмемо файл конфігурації з оновленням, відкриємо центральну базу в Конфігураторі і завантажимо його (Конфігурація-Завантажити конфігурацію з файлу ...). Збережемо ІБ (F7).
2. Зайдемо в і зробимо вивантаження в файл для периферійної бази:
   
   
   • Виділимо план обміну в списку, потім правою кнопкою викликати контекстне меню і викинь пункт «Записати зміни ...».
3. Тепер займемося периферійної ІБ. Відкриємо її в монопольному режимі, щоб нікого з користувачів не було, а також закриємо Конфігуратор. Тепер необхідно запам'ятати вузол, який є головним для поточної бази. Відкриємо Операції-Плани обміну-Вибрати ваш план обміну (наприклад, «За складом»). У списку планів обміну головним вузлом є елемент з жовтою піктограмою. Ця інформація стане в нагоді нам у сьомому пункті. Відкриємо обробку і натиснемо кнопку «Скасувати призначення головного вузла».
4. Тепер відкриємо периферійну ІБ в Конфігураторі і завантажимо той же файл конфігурації, який ми завантажували на першому кроці в центральній базі (Конфігурація-Завантажити конфігурацію з файлу ...). Збережемо ІБ (F7).
5. Змінимо налаштування підтримки (Конфігурація-Підтримка-Налаштування підтримки ...). У діалозі виділимо в таблиці осередок на перетині першого рядка і другий колонки. Потім подвійним натисканням викличемо діалог «Налаштування правил підтримки». У ньому поставимо прапор «Встановити для підлеглих об'єктів» і натиснемо кнопку «ОК». Закриємо діалог настройки підтримки, натиснувши кнопку «Закрити». Зберегти ІБ (F7). Закриємо Конфігуратор.
6. Тепер знову відкриємо периферійну ІБ в монопольному режимі 1С: Підприємство, щоб нікого з користувачів не було, а також закриємо Конфігуратор. Відкриємо обробку УстановкаГлавногоУзлаБД.epf і виберемо план обміну, який ми хочемо встановити головним вузлом (в четвертому пункті ми запам'ятовували цей вузол). Потім натиснемо кнопку «Встановити головний вузол». Після цього поточна ІБ знову стане периферійної.
7. Тепер в поточній ІБ (периферійної) відкриємо плани обміну і завантажимо файл з обміном з Центральної бази, який ми отримали на третьому кроці:
   
   
   • Операції-Плани обміну-Вибрати наш план обміну (наприклад, «За складом»).
8. Якщо все пройшло успішно, то зробимо вивантаження обміну для Центральної бази в поточній ІБ (периферійної):
   
   
   • Операції-Плани обміну-Вибрати наш план обміну (наприклад, «За складом»).
   • Виділимо план обміну в списку, потім правою кнопкою викликати контекстне меню і виберемо пункт «Записати зміни ...».
   • У діалозі вкажемо шлях і ім'я файлу обміну. Натиснемо кнопку «ОК».
9. Тепер спробуємо завантажити цей файл в Центральній базі, відкриємо її в режимі 1С: Підприємство:
   
   
   • Операції-Плани обміну-Вибрати наш план обміну (наприклад, «За складом»).
   • Виділимо план обміну в списку-Правою кнопкою викличемо контекстне меню і вибрати пункт «Прочитати зміни ...»
   • У діалозі виберемо файл обміну. Натиснемо кнопку «ОК».

Щоб уникнути проблем з робочими копіями зробіть спочатку

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

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

На практиці іноді трапляється так, що між сеансами обміну, особливо якщо на периферії погано з каналом, конфігурація головного вузла встигає змінитися двічі. Наприклад, внесли зміни, вивантажили, периферійна база зміни отримала, але ще не застосувала їх, що може зайняти деякий час, і підтвердження ще не прислала. Якщо в цей проміжок внести зміни ще раз і знову вивантажити обмін, то вийде, що центр очікує побачити в периферійному вузлі конфігурацію №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.

Якщо ви не хочете возитися з командним рядком, То можна скористатися однією з обробок, нижче представлена \u200b\u200bта, яку використовуємо ми, вона була знайдена на просторах мережі, і ми внесли в неї лише косметичні правки. Зверніть увагу, обробка підходить лише для звичайного застосування, для конфігурацій на керованому додатку використовуйте ключ запуску Конфігуратора.

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

Тепер нам потрібно актуальна конфігурація з центрального вузла. Для цього відкриємо центральну ІБ в Конфігураторі і виконаємо Конфігурація - Зберегти конфігурацію в файл. Отриманий файл з розширенням cf буде потрібно передати в периферійний вузол.

Потім в периферійному вузлі запускаємо ІБ (попередньо відключивши її від головного вузла) в Конфігураторі і знімаємо з підтримки. Для цього вибираємо: Конфігурація - Підтримка - Налаштування підтримки.

У вікні, спочатку включаємо можливості зміни.

А потім знімаємо конфігурацію з підтримки.

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

• Файл з повідомленням вже завантажувався в базу-приймач. Необхідно вивантажити його з бази-джерела заново.

Помилка «Помилка при копіюванні файлу c FTP ресурсу ... Помилка роботи з Інтернет: Timeout was reached»

• З сайту, через який проходить обмін, не виходить скопіювати потрібний файл. Це може бути пов'язано з повільною роботою вашого інтернету або з проблемами самого сайту.
• Потрібно спробувати повторити обмін через 15-30 хвилин.

Помилка «Редагування даних цього періоду заборонено. Зміни не можуть бути записані ... »

• Офлайн дані містять документи з закритого періоду.
• Потрібно провести обмін під користувачам, які мають право на зміну документів в цьому періоді.

Помилка «Необхідно виконати оновлення конфігурації бази даних. Оновлення може бути виконано в режимі конфігуратора »

Причина: Програмісти поміняли конфігурацію в центрі. Рішення: Оновити змінену конфігурацію в периферійній базі. Для цього:

• Зайти в конфігуратор.
• Виконати пункт меню «Конфігуратор / Оновити конфігурацію бази даних».
• Якщо видається питання з відповідями тільки «Повтор», «Скасування», «Оновити динамічно», натиснути кнопку «Оновити динамічно».
• Якщо видається питання з відповідями тільки «Повтор» і «Скасувати».
  • всім користувачам вийти з 1С.
  • натиснути кнопку «Повтор».
• На питання, що залишилися відповісти ствердно: «Так», «Прийняти», «ОК».
• Закрити конфігуратор.
• Повторити завантаження з центру.

Помилка «Конфігурація не відповідає очікуваної», «Спроба прийому змін від невідомої конфігурації»

• Помилка в базі даних.
• Необхідно звернутися до фахівців.

Для початку привожу список використовуваних мною скорочень:

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

за власним досвід можу сказати, що стикався з двома причинами виникнення помилки:

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

Перераховані дії необхідно виконувати з граничною обережністю, некоректна послідовність чревата повною непрацездатністю РИБ. Тому перед цими діям створення резервних копій ОБОВ'ЯЗКОВО!

В іншому можу тільки побажати удачі!