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.

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

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

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

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

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

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

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

Ця помилка є типовою для. Помилка «Конфігурація вузла розподіленої ІБ не відповідає очікуваної» є системною. В основному виникає через аварійний завершення роботи під час обміну даними по УРІБ.

Вирішити це можна досить простим способом. Розглянемо його.

Інструкція

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

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

3. Збережіть конфігурацію центрального вузла в файл бази даних ( «Конфігурація - Зберегти конфігурацію в файл ...»)

4. Відкрийте конфигуратор бази підлеглого вузла.

Отримайте 267 відеоуроків по 1С безкоштовно:

5. Зніміть конфігурацію підлеглого вузла з підтримки (Конфігурація - Підтримка - Налаштування підтримки - Зняти з підтримки):

6. Завантажте конфігурацію бази даних ( «Конфігурація - Завантажити конфігурацію з файлу ...»).

8. Після реструктуризації необхідно зайти в режим підприємства і встановити головний вузол конфігурації. Це зробити можна за допомогою спеціальної обробки -. Обробка працює як в режимі керованого застосування, так і в режимі звичайного застосування.

9. У обробці необхідно вибрати головний вузол і натиснути «Виконати»:

10. Готово! Спробуйте запустити обмін, система повинна коректно виконати обмін.

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

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

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

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

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

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

ПЕРША МЕТОДИКА

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

Послідовність дій:

вивантажуємо з ЦБ cf-файл;
одв'язуємо УБ від РИБ (метод УстановітьГлавнийУзел, готову обробку можна знайти в додатку або в інших публікаціях);
замінюємо конф. УБ на розвантажений у першому кроці cf-файл, для цього користуємося меню "Завантажити конфігурацію з файлу" (а не порівнянням-об'єднанням !!!);
Відновлюючи ознака РИБ для УБ.

У більшості випадків цих дій більш ніж достатньо, що відновити обмін, але не завжди ...

ДРУГА МЕТОДИКА

Застосовується в разі, якщо перша методика не спрацювала, а вивантажити заново вузол не представляється можливим.

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

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

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

Отже, послідовність дій:

виконуємо дії 1 - 4 першої методики;
вивантажуємо з УБ файл обміну, але не завантажуємо його в ЦБ;
вивантажуємо з ЦБ файл обміну, але не завантажуємо його в УБ;
в файлі обміну з ЦБ замінюємо блок, що містить інформацію про зміни конфігурації і хеші (Digest1 і Digest2), на блок хеш з файлу УБ (приклад див. нижче)
виробляємо завантаження файлу з 4-го пункту в УБ;
обов'язково Перезаписуємо файл обміну з УБ (2-й пункт)! цей файл не повинен бути завантажений при обміні в ЦБ!
для перевірки робимо кілька послідовних обмінів.

Якщо при обміні використовується стиснення даних, то або відключаємо стиснення, або спочатку розпаковуємо файл, змінюємо, потім запаковуємо назад і відправляємо.

Блок файлу обміну з ЦБ

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

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

106.0
00000000000000000000000000000000
11651cf680807e97a5dc0d1ed7f901b0

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

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

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

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

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

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

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

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

ПЕРША МЕТОДИКА

Послідовність дій:

вивантажуємо з ЦБ cf-файл;
одв'язуємо УБ від РИБ (метод УстановітьГлавнийУзел, готову обробку можна знайти в додатку або в інших публікаціях);
замінюємо конф. УБ на розвантажений у першому кроці cf-файл, для цього користуємося меню "Завантажити конфігурацію з файлу" (а не порівнянням-об'єднанням !!!);
Відновлюючи ознака РИБ для УБ.

У більшості випадків цих дій більш ніж достатньо, що відновити обмін, але не завжди ...

ДРУГА МЕТОДИКА

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

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

Отже, послідовність дій:

виконуємо дії 1 - 4 першої методики;
вивантажуємо з УБ файл обміну, але не завантажуємо його в ЦБ;
вивантажуємо з ЦБ файл обміну, але не завантажуємо його в УБ;
в файлі обміну з ЦБ замінюємо блок, що містить інформацію про зміни конфігурації і хеші (Digest1 і Digest2), на блок хеш з файлу УБ (приклад див. нижче)
виробляємо завантаження файлу з 4-го пункту в УБ;
обов'язково Перезаписуємо файл обміну з УБ (2-й пункт)! цей файл не повинен бути завантажений при обміні в ЦБ!
для перевірки робимо кілька послідовних обмінів.

Блок файлу обміну з ЦБ

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

106.0 00000000000000000000000000000000 11651cf680807e97a5dc0d1ed7f901b0

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

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

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

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

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

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

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

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

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

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

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

Обмін проходить дуже довго, зависає

Можливі причини:

Надходить багато даних.
- Потрібно звернутися до відправника, чи виконував він групова зміна документів (проведення, заміна реквізитів і т.д.).
- Якщо так, залиште комп'ютер з обміном на ніч.
Великий файл не може скачати з інтернету.
- Якщо файл має великий розмір (80-100 Мб і більше), то, можливо, 1С просто не може його завантажити.
- Необхідно завантажити файл і завантажити його в 1С вручну (можливо за допомогою фахівців).
  - пункт меню «Операції» / Плани обміну / Повний / Кнопка на панелі «Прочитати повідомлення».
База пошкоджена:
- Спробуйте
Якщо ці дії не допомогли - доведеться звернутися до фахівців.

Якщо виправити помилку не вдалося, телефонуйте екстреної підтримки +7 (8512) 64-55-05.
Наш фахівець допоможе вам, в якому б місті ви не знаходилися.