При динамічному оновленні, в процесі збереження конфігурації, вилетіла база 1С і відмовилася заходити в режим Конфігуратора, видаючи повідомлення "Увага. При оновленні даних, після останньої реструктуризації, сталася помилка. Повторити оновлення?", Якщо відповісти ствердно, то з'являлося повідомлення "Виявлена незавершена операція збереження конфігурації. Для продовження роботи необхідно завершити операцію. ", після чого Конфігуратор закривався.
Приводом до написання даної статті, послужило падіння бази під час збереження конфігурації, при динамічному оновленні. Здавалося б скільки вже разів попереджали - "Не робіть динамічне оновлення на 8.2!", Але іноді, без нього просто не обійтися.
Отже нічого не віщувало біди, але раптом під час збереження конфігурації, 1С видала помилку про пошкоджений Config і благополучно закрилася. Думаючи, що проблема вирішиться дуже просто, я заново відкрив Конфігуратор і прочитав наступне повідомлення:
"Увага. При оновленні даних, після останньої реструктуризації, сталася помилка. Повторити оновлення?" "Та ні"
Все ще перебуваючи в радісному настрої, я натиснув на "Так". 1С-ка трохи задумалася і видала нове повідомлення:
"Виявлена незавершена операція збереження конфігурації. Для продовження роботи необхідно завершити операцію."
І після натискання на кнопку "Ок" це вікно закрилося разом з конфігуратором. Ось тут-то я і почав підозрювати, що все буде не так просто.
Продовжуючи копати глибше, я натрапив ось на цю чудову статтю VanDiesel1. Ось тільки цей метод не працює, якщо бази знаходяться в різних кластерах, але трохи подумавши я все ж знайшов рішення. Прочитавши статтю я дізнався, що вся справа в "зіпсувалися" таблицях dbo.Config і dbo.ConfigSave.
Отже, відставити паніку!
1. Перевіряємо чи є у нас конфігурація ідентична звалилася. У моєму випадку, їх було цілих 4, так як працюємо через Сховище Зміни. Можна використовувати і не зовсім ідентичну конфігурацію, але будьте готові до того, що тоді всі зміни доведеться вносити заново (якщо звичайно у вас немає Сховища Зміни).
2. Далі заходимо в SQL Management Studio та очищаємо таблиці dbo.Config і dbo.ConfigSave звалилася бази за допомогою нехитрого запиту (для того щоб його написати, натисніть "New Query" або "Новий Запит", ну а щоб виконати - "Execute" і "Виконати" відповідно):
Truncate table dbo.Config
Truncate table dbo.ConfigSave
3. Все, тепер залишилося "залити" ці ж таблиці з хорошою конфігурації. Як я вже написав вище, спосіб запропонований VanDiesel1 мені не допоміг, так як робоча база і всі бази з хорошими конфігураціями, перебували в різних кластерах. Почитавши мануал до SQL Management Studio. я натрапив на таку можливість, як імпорт таблиць з однієї бази в іншу і негайно вирішив нею скористатися. Отже в SQL Management Studio стаємо на зіпсовану базу і клацаємо правою кнопкою миші, далі Tasks -> Import Data.
Відкриється візард в якому:
- a) На другій сторінці вказуємо сервер і базу з якої ми будемо брати дані.
- b) На третій вказуємо базу приймач.
- с) На четвертій вибираємо "Копіювати дані з таблиць".
- d) На п'ятій відзначаємо галками таблиці dbo.Config і dbo.ConfigSave.
- e) На шостий дивимося, щоб не було помилок і процес завантаження пройшов успішно.
4. Ось власне і все, можна пробувати запускати 1С.
P.S. В ході пошуку рішення дізнався, що цей спосіб відновлення, є недокументованим 1С і всі дії, ви виконуєте на свій страх і ризик, а документований спосіб - це відновлення з резервної копії.
10. ІРЛІ Берд (EarlyBird) 1 21.07.13 00:18 Зараз в темі
1. Перевіряємо чи є у нас конфігурація ідентична звалилася. У моєму випадку, їх було цілих 4, так як працюємо через Сховище Зміни. Можна використовувати і не зовсім ідентичну конфігурацію, але будьте готові до того, що тоді всі зміни доведеться вносити заново (якщо звичайно у вас немає Сховища Зміни).
2. Далі заходимо в SQL Management Studio та очищаємо таблиці dbo.Config і dbo.ConfigSave звалилася бази за допомогою нехитрого запиту (для того щоб його написати, натисніть "New Query" або "Новий Запит", ну а щоб виконати - "Execute" і "Виконати" відповідно):
Truncate table dbo.Config
Truncate table dbo.ConfigSave
3. Все, тепер залишилося "залити" ці ж таблиці з хорошою конфігурації. Як я вже написав вище, спосіб запропонований VanDiesel1 мені не допоміг, так як робоча база і всі бази з хорошими конфігураціями, перебували в різних кластерах. Почитавши мануал до SQL Management Studio, я натрапив на таку можливість, як імпорт таблиць з однієї бази в іншу і негайно вирішив нею скористатися. Отже в SQL Management Studio стаємо на зіпсовану базу і клацаємо правою кнопкою миші, далі Tasks -> Import Data.
Відкриється візард в якому:
a) На другій сторінці вказуємо сервер і базу з якої ми будемо брати дані.
b) На третій вказуємо базу приймач.
с) На четвертій вибираємо "Копіювати дані з таблиць".
d) На п'ятій відзначаємо галками таблиці dbo.Config і dbo.ConfigSave.
e) На шостий дивимося, щоб не було помилок і процес завантаження пройшов успішно.
4. Ось власне і все, можна пробувати запускати 1С.
37. andrey dyak (dyak84) 23.07.13 17:19 Зараз в темі
38. Петро Суренков (lord_soth) 276 23.07.13 17:28 Зараз в темі
11. ІРЛІ Берд (EarlyBird) 1 21.07.13 00:21 Зараз в темі
12. Євген '(WanGoff) 123 21.07.13 1:57 Зараз в темі
13. ІРЛІ Берд (EarlyBird) 1 21.07.13 2:43 Зараз в темі
ситуація робоча, і якщо програміст 1С не вирішить таку проблему без сторонньої допомоги - то йому незачОт.
18. Євген '(WanGoff) 123 21.07.13 14:20 Зараз в темі
14. Петро Суренков (lord_soth) 276 21.07.13 10:28 Зараз в темі
(12) WanGoff, в обов'язки програміста 1С в великих фірмах, не входить адміністрування бази і вже тим більше, у нього немає доступу до серверів.
(7) Gilev.Vyacheslav, спасибі за посилання, але що з наведеного в ній, мало б мені допомогти? Правильна відповідь - нічого.
17. В'ячеслав Гилева (Gilev.Vyacheslav) 1 756 21.07.13 14:19 Зараз в темі
(14) lord_soth, дивись пункт 7.7
19. Петро Суренков (lord_soth) 276 21.07.13 16:14 Зараз в темі
(17) Gilev.Vyacheslav, в тому-то і справа, що конфігурація навіть не близька до типової, так що 7.7 не підходить.
15. Олексій Бочков (Aleksey.Bochkov) 2775 21.07.13 11:43 Зараз в темі
(0) мені завжди допомагав інший, менш болісний спосіб - видалити 2 записи в таблиці з конфігурацією:
20. В'ячеслав Гилева (Gilev.Vyacheslav) 1 756 21.07.13 19:32 Зараз в темі
але пройде кілька років, і ви самі зіткнетеся з тим як прочитаєте у чергового "винахідника" написане тут, вся історія розвивається по колу.
21. Петро Суренков (lord_soth) 276 21.07.13 19:48 Зараз в темі
історія розвивається по колу.
(20) Gilev.Vyacheslav, ви маєте рацію і дійсно, давайте далі не продовжувати.
22. Владислав Свинцов (VSvintsov) 13 21.07.13 20:32 Зараз в темі
23. Петро Суренков (lord_soth) 276 21.07.13 22:17 Зараз в темі
(22) VSvintsov, та зараз вирішили на стример копію робити. )
24. Олександр Мілютін (sanfoto) 470 22.07.13 6:36 Зараз в темі
АЛЕ починаючи з релізу движка 8.2.17 (перевіряв починаючи з 8.2.17.169) - все це НЕ актуальні. глюків більше немає!
25. Петро Суренков (lord_soth) 276 22.07.13 6:59 Зараз в темі
(24) sanfoto, у нас якраз був 8.2.16. (Яким чином перевіряли? Чи є підтвердження від 1С?
29. Олександр Мілютін (sanfoto) 470 22.07.13 12:02 Зараз в темі
у нас як раз був 8.2.16. (Яким чином перевіряли?
В роботі перевіряли як ще)) і так ніби як на офіційному було написано що виправили демонічних оновлення в 8.2.17.
Кілька місяців 8.2.17.169 - Динамічні (вже не демонічний можна назвати) оновлення (кілька прогерія) дуже часті - глюків зі зльотом конфігурації немає взагалі.
ЗИ:
Безпосередньо в ЦЕНТРАЛЬНОЇ БАЗІ нічого не пишемо - ВСЕ через "Сховище Зміни". у кожного прогерія своя БД.
30. Петро Суренков (lord_soth) 276 22.07.13 12:32 Зараз в темі
28. Сергій Гуков (SirYozha) 172 22.07.13 11:41 Зараз в темі
(24) теж цікавить, яким чином перевіряли? )
26. Андрій Конєв (Infector) 93 22.07.13 8:58 Зараз в темі
Ще трошки по темі - можливо просто збіг, але помітили цікаву штуку - якщо перед динамічним оновленням конфігурацію зберегти (Ctrl + s, тільки потім F7) ймовірна проблема з базою проявляється менш жорстко - можна успішно вигнати всіх користувачів і оновити базу без чаклунства в SQL
27. vicmos victor (vicmos) 40 22.07.13 10:09 Зараз в темі
Спасибі, рішення простенько і зі смаком.
31. Андрій Конєв (Infector) 93 22.07.13 12:55 Зараз в темі
8.2.17.ххх не панацея, падає, але тільки значно рідше. Тому не забуваємо робити Бекапи перед тим як оновлюватися.
32. Олександр Мілютін (sanfoto) 470 22.07.13 13:08 Зараз в темі
Тому не забуваємо робити Бекапи перед тим як оновлюватися.
навіщо Повний БекапКаждий раз? якщо падає тільки таблиця конфігурації.
якщо вже передбачати таку можливість то робимо як в (24) sanfoto, тобто НЕПІШЕМ ВІДРАЗУ в центральній а юазаем "Сховище конфігурації" або пишемо код в "Окремою БД".
ПС:
Хоча бекапи у нас Всетаки робляться))
1) Повний бакап раз в Доба -
2) і Транзакшен-лог щогодини. есно все автоматом))
ПС2:
У нас програма працює 24/7 виходу немає - крім динамічного оновлення - кого стосується той перезапустить програму (або ми самі "нужденним" допоможемо перезапустити)))).
42. Євген (Evmil) 13 06.08.14 12:42 Зараз в темі
(31) Infector, якщо при динамічному оновлення база вилетіла, то потім виганяємо користувачів, продовжуємо оновлення монопольно і все ОК при платформі> 8.2.16.
33. Андрій Конєв (Infector) 93 22.07.13 13:19 Зараз в темі
За великим рахунком головне мати в бекапе конфігурацію до зміни, щоб не так образливо було частина оновлено втрачати при ймовірному відновленні. Якщо в нічному бекапе все є, він, звичайно ж, влаштовує.
PS: до сховища конфігурації поки не доросли.
35. Геннадій Зімін (kenza) 22.07.13 15:48 Зараз в темі
(33) Infector, згоден. Постійно тестую зміни конфігурації локально, потім вже заливаю нову. Стара конфігурація так само зберігається. Динамічне оновлення взагалі більше ніколи не використовую, так як вже переконався, що це ні до чого доброго не приводить)
34. diver.sun diver.sun (diver.sun) 22 22.07.13 15:15 Зараз в темі
Стикався з такою ж ситуацією, коли проводив не динамічне а звичайне оновлення, і погас сервер HASP. обійшов проблему наступним чином: Очистив таблицю configsave потім відсортував таблицю config і подивився що змінювалося останнім, там був якась запис ознака. назва хоч убийте не згадаю. він мав дату модифікації більшою ніж записи даних. і нульовий розмір, я його видалив, і база взагалі забула що хотіла оновиться
36. Олексій Соловйов (Silenser) 433 23.07.13 11:45 Зараз в темі
Насправді досить один раз написати скрипт, який би бекап 2 таблички з конф в нові таблички всередині тієї ж бази через select into. При його запуску перед оновленням косяк динаміки вирішується за 1 хвилину. Простіше попередити, ніж лікувати;)
39. Марина Чирина (chmv) 24.07.13 12:38 Зараз в темі
40. Oberonm (oberonm) 9 30.07.13 11:37 Зараз в темі
41. Michael Cher (mmch) 119 14.08.13 13:15 Зараз в темі
Не думав, що в нагоді, а сьогодні стало в нагоді! Спасибі, Метод робочий, перевірено особисто =)