При обновлении данных, после последней реструктуризации, произошла критическая ошибка. Повторить обновление?
20 июня, 2019
20 июня, 2019
Дано
При применении конфигурации в РИБ возникает критическая ошибка и конфигуратор аварийно завершается.
Затем, при попытке зайти в конфигуратор, 1С выдает следующее сообщение: “При обновлении данных, после последней реструктуризации, произошла критическая ошибка. Повторить обновление?”
Выбор любого из действий ни к чему не приводит и если ответить утвердительно, то повтор обновления не происходит.
Попытка вернуться к конфигурации БД через параметр командной строки /RollbackCfg так же не увенчалась успехом. При использовании этого метода в диспетчере задач видно, что 1С запускается на 2-3 секунды и даже не успевает развернуться в памяти, и фактически не отрабатывает.
Версия платформы 8.3.13.1809 (клиент-сервер)
Решение
На просторах интернета конечно же есть решение, которое реально помогает, но нужно заметить его небезопасность и то, что все действия нужно выполнять с осторожностью перепроверяя свои действия.
Итак суть решения состоит в том чтобы очистить некоторые данные в таблицах БД (SQL), которые говорят системе о незавершенном обновлении. Нужно выполнить запросы к БД.
Конечно же я настоятельно рекомендую выполнять все действия при наличии резервной копии БД, причем средствами сервера БД. Но если на это нет времени, то мы себя немного обезопасим резервной копией таблиц.
select * into Config_tmp from Config select * into ConfigSave_tmp from ConfigSave delete from ConfigSave delete from config where FileName = 'commit' delete from config where FileName = 'dynamicCommit' delete from config where FileName = 'dbStruFinal'
Кстати о возможности возврата к отправной точке, первые два select копируют две таблицы, с которыми мы будем выполнять действия и создают временные таблицы Config_tmp и ConfigSave_tmp на всякий случай для возможности возврата.
первый из delete удаляет все данные таблицы ConfigSave.
остальные удаляют определенные записи из таблицы config.
После выполнения этих действий вы сможете зайти в 1С в режиме конфигуратора, при этом все ваши изменения будут потеряны.
Если все прошло удачно, то нужно удалить временные таблицы которые мы создавали.
drop table Config_tmp drop table ConfigSave_tmp
Собственно это решение было найдено в интернете и протестировано в реальных условиях и показало результат. Огромное спасибо тому кто потратил время, на изучение этого вопроса и поделился этой информацией.
вылетел конфигуратор при обновлении , терь не могу ни в конф ни в предприятие !! |
Я |
18.10.12 — 10:40
Запускаю конфигуратор , пишет :
Внимание!! при обновлении данных после последней реструктуризайции произошла критическая ошибка Повторить обновления?
если жму нет то просто захлопывается. если жму да то сообщает что есть сотня активных сеансов 
в предприятие тоже не входит !!!!!!
1 — 18.10.12 — 10:41
во врем яобновления вылетел с ошибкой чтения какого то файла на сервере УПП 1.3 клиент серверная
2 — 18.10.12 — 10:41
Администрирование — Активные пользователи, кто там?
3 — 18.10.12 — 10:43
была тут тема, мне помогла..создал на сервере копию(архив) и скопировал из архива таблицы конфиги в рабочую..
4 — 18.10.12 — 10:43
(2) в консоли? толпа народа. но обновление я динамическое прводил зачем ему всех выгонять не понимаю
5 — 18.10.12 — 10:44
(3) БД 200 гигов скока я ща буду копии создавать
6 — 18.10.12 — 10:45
перезапусти сервер 1С
7 — 18.10.12 — 10:45
(5) тебе нужно таблицы конфиги скопиравть..а не данных..
8 — 18.10.12 — 10:45
(4) А ты смелый… 
9 — 18.10.12 — 10:45
(4) над выгнать всех и запуститься монопольно — новые пользователи подключаться не смогут
10 — 18.10.12 — 10:46
(5)есть шанс все 200гигив потерять
11 — 18.10.12 — 10:46
(8) (9) не говорите ерунды. во первых есть фулбекап утренний во вторых демоническое зло но без него НЕЛЬЗЯ кругломсуточная работа и все такое.
12 — 18.10.12 — 10:46
(5) А нет более-менее новой копии?
Если нет, то разворачивать архив.
13 — 18.10.12 — 10:47
(11) правильно расставляйте приоритеты! юзеров нафиг пока базу не восстановите
рискуете
14 — 18.10.12 — 10:47
(4), Выгонять придется или откатывай обновление.
15 — 18.10.12 — 10:48
+(13) но это ваше дело конечно)
16 — 18.10.12 — 10:48
(0) выгонять.
17 — 18.10.12 — 10:48
У меня такое чувство что ктото завозил ИТС к клиенту и его по быстрому попросили упп обновить.
18 — 18.10.12 — 10:49
(17) да довольно частая ошибка на больших базах еще и с распределенкой и т.п. Там вродь просто перезайти надо монопольно и все само вылечится
19 — 18.10.12 — 10:49
20 — 18.10.12 — 10:50
тогда пускай до ночи ждет, потом выгоняет.
21 — 18.10.12 — 10:50
(0) попал…
22 — 18.10.12 — 10:50
(11) Демоническое обновление — зло, безо всяких «но».
А на счет «без него нельзя» — так это потому, что организовать работу не можешь…
23 — 18.10.12 — 10:52
(18) +1, все просто
(20) новые подключения к базе и сейчас не возможны, только те кто туда уже подключены могут работать) хз чего ТС ждет
24 — 18.10.12 — 10:55
(13) +1
При любых подозрениях на сбои (программные или аппаратные), тут же всех выкидывать и делать архив.
Мы один раз попали, попробовав на ходу перестроить рейд-массив, когда один из дисков вылетел, теперь ученые.
25 — 18.10.12 — 10:57
(19)
Надо сверху подписать: «Уронил базу. Скоро встреча с директором».
А снизу: А в кулаке у нее вазелин.
26 — 18.10.12 — 11:00
(23) заявление пишет. И письмо будущему программисту.
27 — 18.10.12 — 11:02
(17) чувства в сторону, я знал что делал.
откинул всех ребутнул службу пробую войти в конфигуратор
28 — 18.10.12 — 11:03
(27) Видимость нулевая. Сбросил топливо, включил пассажирам рамштайн. Иду на посадку по приборам…
29 — 18.10.12 — 11:03
(27) Прямо как пожарный, все вон иду вас спасать беру вину на себя! Ничо тс ничего страшного)
30 — 18.10.12 — 11:04
такое впечатление что 80% присутствующих потирают руки что база упала. для таких сообщаю что есть фулбекаб на 6 утра и каждый час дифф бекапы. потеря данных максимум 20-30 минут
31 — 18.10.12 — 11:05
(30) Да нет сочувствууем, просто ситуация не критическая поэтому можем постебатся над несколько необычной реакцией ТС.
32 — 18.10.12 — 11:06
Да мы просто наблюдаем.
(долил чая и взял еще печенек)
33 — 18.10.12 — 11:06
(19)Хватит!
34 — 18.10.12 — 11:06
Было такое, помог перезапуск монопольно…
Динамическое обновление зло… но такое заманчивое =)
35 — 18.10.12 — 11:07
неполучилось ограничить открытие новых сеансов после просто ребута службы . все равно всех пускает все лезут монопольно попасть не могу ребучу сервак
36 — 18.10.12 — 11:08
(30) да не потираем руки, было такое и не раз…все лишается монопольным запуском
просто тянуть время не стоит
37 — 18.10.12 — 11:08
(35) Про блокировку базы слыхал — не?))
38 — 18.10.12 — 11:09
(36) нафига? опять зайдут после ребута, если их много будут стучаться
39 — 18.10.12 — 11:09
(35) базу заблокировать и они сами отпадут
40 — 18.10.12 — 11:09
(38) ну вообщето запрет на новые сеансы раньше всегда помогал
41 — 18.10.12 — 11:09
(38) — > (35)
42 — 18.10.12 — 11:10
43 — 18.10.12 — 11:10
(40) имеенно, ребутить то зачем только ?))
44 — 18.10.12 — 11:12
как заблокировать базу от всех а. непомогает запрет на вход
45 — 18.10.12 — 11:12
не могу попасть монопольно
46 — 18.10.12 — 11:13
(44) Что есть «запрет на вход»?
Ставь блокировку базы с паролем, епта.
47 — 18.10.12 — 11:14
(44) епт.. переименуй в консоли
48 — 18.10.12 — 11:14
(46) в консоли в свойствах бд ставлю глаку запретить новые сеансы. а Ваш метод где модно реализовать епта ? ну подскажите видно же что читать мне некогда
49 — 18.10.12 — 11:15
(47) спасиб дело
50 — 18.10.12 — 11:16
вру…. не выйдет
51 — 18.10.12 — 11:16
вижу. не выходит
52 — 18.10.12 — 11:17
на скуле мож переименовать
53 — 18.10.12 — 11:17
«ставлю глаку запретить новые сеансы»
должно работать
54 — 18.10.12 — 11:18
(53) типа мне скучно и я шучу? не срабатывает
55 — 18.10.12 — 11:18
(48) «Блокировка начала сеансов» — это и есть блокировка. Жди минут 5-15, вылетят все.
56 — 18.10.12 — 11:18
(55) он пускает даже новых
57 — 18.10.12 — 11:18
(54) У тебя неправильная 1С
58 — 18.10.12 — 11:19
+(55) После установки блокировки можно из консоли всех повыкидывать (позавершать сеансы).
59 — 18.10.12 — 11:19
(56) Пароль блокировки задал?
60 — 18.10.12 — 11:21
сработало. кто нить подскажет какой ключ в ярлыке чтобы пустило
61 — 18.10.12 — 11:22
(60) /UC
62 — 18.10.12 — 11:23
сейчас такой
63 — 18.10.12 — 11:23
«C:Program Files (x86)1cv82common1cestart.exe»
64 — 18.10.12 — 11:23
(60) /uc password
65 — 18.10.12 — 11:24
(63) Нужно так:
C:Program Files1cv828.2.15.318bin1cv8.exe /UC123456
66 — 18.10.12 — 11:25
пустил. думает
67 — 18.10.12 — 11:26
удаленный хост принудительно разорвал соединение пишет
68 — 18.10.12 — 11:29
ошибка сетевого доступа к севреру виндовс сокет удаленный хост принудительно разорвал существующее подключение line = 1033 file =
69 — 18.10.12 — 11:29
(68) Версия сервера и клиента одинаковая?
70 — 18.10.12 — 11:30
а с чего бы она поменялась
71 — 18.10.12 — 11:30
Кэши чистил?
72 — 18.10.12 — 11:32
(70) В (65) версия клиента жестко указана и может не соответствовать последней установленной…
73 — 18.10.12 — 11:33
(72) см (63) там ключ прописал
74 — 18.10.12 — 11:35
(73) И че, работает?)) Раньше не работало так… Пойду проверю
75 — 18.10.12 — 11:35
беру ярлык жостко моей платформы — не получится восстанавливаю бекап
76 — 18.10.12 — 11:36
(75) Давно бы параллельно запустил восстановление бекапа и оттуда таблицы конфигурации сейчас взял.
77 — 18.10.12 — 11:37
(76) я не знаю как это сделать
78 — 18.10.12 — 11:38
+(74) Ааааа)) Внатуре, работает!)) Наконец-то!)))
79 — 18.10.12 — 11:38
ищи на инфостарте
Восстановление SQL базы 1С 8.2. рухнувшей во время сохранения конфигурации.
80 — 18.10.12 — 11:38
(79) проще 20 минут работы потерять чем ща 3 часа читать
81 — 18.10.12 — 11:41
(80) нда…. там 3 всего-то 2 простеньких запроса по 1 строчке
82 — 18.10.12 — 11:42
2. Очищаем таблицу dbo.config нашей базы в которой лежит наша порушенная конфа. Это можно сделать из SQL- Profiler, к примеру запустив в нем команду:
Use Base2009
go
Delete From [DBO].[Config]
go
где Base2009 имя рухнувшей базы.
Примечание: где-то в сети читал непроверенную инфу, что иногда помогает очистка таблицы dbo.ConfigSave, в которой, якобы, лежит накатываемая конфа. В нашей базе она оказалась пустая, поэтому чистить пустую таблицу, понятно не стал. Возможно — можно как-нибудь обмануть и оживить базу 1С, используя данную таблицу но, не зная механизм работы 1С с этой таблицей, ничего не буду говорить в плане действий, применительно к ней.
3. Копируем таблицу из базы с целой конфигурацией, в нашу порушенную базу. В моём случае обе базы были на одном сервере поэтому команда копирования в SQL-Profiler выглядела так.
insert into [base2009].[Dbo].[Config] select * from [BaseCopy].[Dbo].[Config]
go
где base2009 — имя рухнувшей базы, BaseCopy имя базы с копией конфигуратора
4. Запускаем 1С, и в случае успеха — прыгаем, как я от радости, что удалось оживить базу без каких-либо потерь информации.
83 — 18.10.12 — 11:42
ну и с ConfigSave провернуть это же
84 — 18.10.12 — 11:43
не чокаясь.. за базу..
85 — 18.10.12 — 11:51
(82) (83) ту оставил на досуге потренируюсь сейчас восстанавлдиваю из архива 10 утра. слава sql серверу и его архивированию
86 — 18.10.12 — 11:54
По 2й, за Скуль!
87 — 18.10.12 — 11:55
мне базу запустить и я 3 злпом могу
88 — 18.10.12 — 12:03
наверно три стакана надо че стопками организм травить
89 — 18.10.12 — 12:10
(85) Славить будешь, когда восстановленная из бэкапа база заработает 
90 — 18.10.12 — 15:53
да нет тут проблем быть не могло восстановил со скулевого бекапа все работают
LamerSuper
91 — 18.10.12 — 16:41
Пару раз уже случалось увидеть такую надпись при обновлений конфигурации 1С. Причем не важно на какой платформе, что на 8.3.6, что на более новых 8.3.12. И что то мне кажется, что эта еще одна причуд системы, обычными методами в виде галочек, кнопочек и других атрибутов интерфейса, реализовано в ближайшее время не будет.
И мы остаемся с возможностью увидеть такое:
Чтобы не искать в следующий раз, запишу заметку на будущее.
С файловыми базами я не работаю, по этому и проблем как таковых для меня нет. Если возникают проблемы:
— Чистим кеш на локальном компьютере.
— Запускаем обработку chdbfl.exe для проверки конфигурации.
— Если не помогло, лезем в файлы базы. Находим обработку Tool_1CD.exe и с помощью ее редактируем файлы
— Есть метод описанный в статье https://infostart.ru/public/182889/
Фактически таблицы SQL базы и файловой не отличаются. По этому переходим к описанию действий на SQL:
— сперва смотрим, что есть в таблице dbo.configsave. Если что то там есть, удаляем : delete from configsave
— далее, если запустить profiler первое сообщение в 1С выводится после запроса select * from Config WHERE FileName = ‘commit’. Удаляем, чтобы сообщение не выводилось: delete from config where FileName = ‘commit’
— так же сообщение выводится после запроса select * from Config WHERE FileName = ‘dbStruFinal’. Удаляем тоже его: delete from config where FileName = ‘dbStruFinal’
Подводим итог:
Все изменения хранятся в таблице configsave. Если она пуста, а присутствует флаг для обновления конфигурации, данные копируются в таблицу config и следовательно затирают пустыми.
Список команд в SQL которые нужно выполнить последовательно,для того чтобы отменить обновление:
—delete from configsave
—delete from config where FileName = ‘commit’
—delete from config where FileName = ‘dynamicCommit’
—delete from config where FileName = ‘dbStruFinal’
Напоминаю, изложение данного материала не являются призывом к действию, а служит только для информации и ознакомления, которую читатель вправе сам выбирать, использовать или нет. Спасибо.
- Home
- /
- Knowledgebase
- /
- 1С
- /
- Ошибки
- /
- Разработка
- /
- Ошибка: При обновлении данн…
Ошибка: При обновлении данных после последней реструктуризации произошла критическая ошибка
Источник
Решение:
1. Создать копии таблиц Config и ConfigSave (на случай восстановления).
SELECT * INTO Config_copy FROM [Config]
;
SELECT * INTO ConfigSave_copy FROM [ConfigSave]2. Удалить все записи из таблицы ConfigSave (содержит обновление)
DELETE FROM [ConfigSave]3. Удалить три записи из таблицы Config (информация о незаконченном процессе обновления конфигурации)
DELETE FROM [Config] WHERE FileName IN ('commit','dbStruFinal','dynamicCommit')При обновлении конфигурации 1С произошел сбой, программа завершила свою работу по ошибке. Затем, при попытке зайты в конфигуратор, стало выдаваться предупреждение: «При обновлении данных после последней реструктуризации произошла критическая ошибка. Повторить обновление?». Если ответить «Нет», то программа просто завершает свою работу, в случае же положительного ответа выводится сообщение «Обнаружена незавершенная операция сохранения конфигурации. Для продолжения работы необходимо завершить операцию.» и программа также закрывается.
Еще ошибка может быть следующая: Нарушена целостность структуры конфигурации. В этом случае, в первую очередь, нужно попробовать почистить кэш 1С. Если не поможет, то читаем дальше.
Самый простой вариант решения данной задачи — восстановление из резервной копии. Но очень не хотелось терять последние введенные за день данные. Поэтому я решил разобраться в вопросе более досканально.
Выяснилось, что все измененные объекты конфигурации программа хранит в таблице configsave. Но в моем случае табличка оказалась пустая. При обновлении конфигурации программа снача копирует все изменения из таблицы configsave в таблицу config, затем очищает первую.
Если имеется база данных с идентичной конфигурацией, то можно полностью перенести из нее таблицу config в испорченную базу. Либо можно удалить все зафиксированные изменения. В этом случае алгоритм восстановления примерно следующий:
- Если в таблице configsave есть данные, то таблицу нужно очистить: delete from configsave
- delete from config where FileName = ‘commit’
- delete from config where FileName = ‘dynamicCommit’
- delete from config where FileName = ‘dbStruFinal’
Добавлено 03.10.2019:
Если то, что описано выше не помогло, то можно перенести конфигурацию с рабочей копии базы (если таковая имеется). Например, если у вас имеется копия базы с такой же конфигурацией, но за вчерашнее число и не хочется терять введенные за сегодня данные.
Для этого выполним следующий запрос:
USE [ИмяРабочейБазы]
DELETE FROM [DBO].[ConfigSave]
DELETE FROM [DBO].[Config]
INSERT INTO [ИмяРабочейБазы].[Dbo].[Config] SELECT * FROM [ИмяКопииБазы].[Dbo].[Config]
GO