При обновлении данных, после последней реструктуризации, произошла критическая ошибка. Повторить обновление?
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
Собственно это решение было найдено в интернете и протестировано в реальных условиях и показало результат. Огромное спасибо тому кто потратил время, на изучение этого вопроса и поделился этой информацией.
Пару раз уже случалось увидеть такую надпись при обновлений конфигурации 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’
Напоминаю, изложение данного материала не являются призывом к действию, а служит только для информации и ознакомления, которую читатель вправе сам выбирать, использовать или нет. Спасибо.
При обновлении конфигурации вылетела 1С. После чего наотрез отказалась входить в базу. При этом в конфигураторе выдавалось сообщение «Внимание!!! При обновлении данных, после последней реструктуризации, произошла критическая ошибка. Повторить обновление?» Потом выходило сообщение «Обнаружена незавершённая операция сохранения конфигурации. Для продолжения необходимо завершить операцию». Горела кнопка Ок — на этом работоспособность конфигуратора и базы заканчивалась.
Предистория.
Два дня назад осуществили переход с 8.1 на 8.2 — меняли конфу УПП 1.2… на 1.3.22.1. Соответственно куча отличий от типовой конфигурации, которые накатывали — повлекло за собой кучу ошибок. Два дня, не ночуя, меняем конфигурацию в режиме нон-стоп. Конфигуратор сохраняется раз 15 в час. Следовало ожидать, что при сохранении, конфигурация может вылететь, что собственно и произошло. Такие проблемы, в конфе 8.1 — всегда разрешались выходом пользователей, которые еще работали в базе, но уже не могли повторно войти и монопольным доступом. В нашей же новой конфигурации 8.2 база сказала нам «Я устал. Я ухожуй» ), в общем проблема описана в анонсе.
Что было предпринято из правильного и неправильного. И совет о том что делать первым делом.
Первым делом мы в суматохе начинаем искать способы решения возникшей проблемы в интернете. Гугл дает буквально 3 статьи на текущий момент по тексту возникающей ошибки. Перечислю их.
http://www.forum.mista.ru/topic.php?id=534298
http://devtrainingforum.v8.1c.ru/forum/thread.jsp?id=573910
http://sysadmins.ru/post9322239.html
В общем во всех трех статьях ответ на решение текущий проблемы один — «Восстанавливайте базу из бэкапа».
Не стоит говорить о важности бэкапов их регулярности и прочем. Считаю что в плане нас это было хорошим предупреждением, хотя у нас и был бэкап базы после ее сохранения в конфигурации 1.3 но за их регулярностью и тем что они делаются (а винчестер не чистится и прочее) , за этим мало кто следит. Соответственно простите за «капитана очевидность», но если у вас есть свежий бэкап — первым делом и займитесь восстановлением базы из него, не теряйте драгоценное время, за простой которого руководство вас не поблагодарит. Однако можно попытаться оживить «упавшую» базу, что благодаря моей настырности было и предпринято. Отмечу, что другим программистом также были приняты попытки как то оживить базу 1с-вскими способами, но они были безуспешны. Не знаю всего что он делал, но видел попытки запуска 1С в командном режиме сразу с запуском Тестирования и исправления ИБ, которые собственно ничего не запускали.
Я заострил свое внимание на SQL. Небольшой опыт конфигурирования и администрирования баз и типовой набор sql-команд мне знаком, но изложенный ниже способ итак не потребует никаких глубоких знаний и навыков работы с SQL. Я просто подключил логику — если база «упала» в момент сохранения конфигурации, делаем вывод, что в SQL могла порушиться структура одной таблицы (хотя я не знал до этого что конфигурация в 8 версии лежит в одной сиквель таблице) и эта таблица в которой хранится конфигурация базы. а именном таблица dbo.config. Это в последствии я узнал методом «самотыка» и опять же логики, ибо единственное что нашел это местную разработку, мне не помогшую но довольно полезную на будущее, а именно //infostart.ru/public/61114/ Спасибо автору от учетки моего коллеги, с помощью которого я ее скачал. Итак перехожу к самому важному — попытки(!) восстановления базы ибо гарантий никаких я вам, к сожалению, дать не могу и тому есть ряд предустановок, которых у вас может и не быть или как говорится — это не ваш случай…
Требования и непосредственно само восстановление базы.
Итак все что было выше, читать, в случае возникшей проблемы, может и интересно, но необязательно.
(Внимание. Посмотрите обязательно сноску снизу, если хотите попробывать оживить и саму конфигурацию. Сегодня (18.04.2012) путем экспериментов мне это удалось ибо стало жалко недельный труд который был проделан над ней. Таким образом получилось базу оживить оставив старый конфигуратор без всяких копий)
Исходные данные — SQL база 1С 8.2, конфигурация УПП 1.3.22.1 (полагаю описанный способ подойдет для любой эскюэльной базы 8.2). SQL сервер 2005. Ошибка описанная в анонсе и ошибка возникшая в момент сохранения конфигурации! Самое важное и обязательное требование!!! Копия SQL базы с ТАКОЙ ЖЕ КОНФИГУРАЦИЕЙ(!) У нас настроен авто-обмен с другой базой и конфигурации их совпадают. Кроме этого, так как нас трое программистов 1С — у каждого есть выгруженный и относительно свежий файл конфы. По факту подойдет любая база, неважно с какими данными, главное чтобы конфигурация в ней соответствовала структуре метаданных базы. Отмечу тот факт, что конфигурация даже немного отличалась от той, с которой база вылетела. Самое основное, на мой взгляд, требование, чтобы отличия в конфигурации не затрагивали метаданные. Не стоит забывать тот факт, что если конфигурация отличается, то в итоге вы получите рабочую базу но с конфигурацией из вашей копии.
Сам процесс восстановления не займет у вас много времени — буквально пару минут, но крайне рекомендую предварительно сделать бэкап даже «упавшей» базы, а он может занять время. Например у вас будет возможность восстановить базу откатом из log-файла (который у нас к сожалению в суматохе восстановления «грохнули») или еще какой способ. Итак, напомню что где то должна быть SQL база неважно какими данными но с такой же конфигурацией. Если у вас конфигурация представляет из себя «нетроганную» типовую (что подразумевает, что данная проблема возникла в процессе наката новой типовой конфигурации) — можете создать новую пустую базу и залить туда типовую конфу, которая у вас была до этого. В случае, если конфигурация, которую вы нашли, не такая уж свежая — подумайте и примите решение, возможно те отличия с копией конфигуратора, которые вы будете вынуждены повторить в вашей базе, займут много больше времени и ресурсов, нежели потеря информации самой базы данных 1С. Своеобразная палка о двух концах ) Итак…
1. Делаем бэкап рухнувшей базы средствами SQL.
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С, и в случае успеха — прыгаем, как я от радости, что удалось оживить базу без каких-либо потерь информации.
5. (Капитан очевидность) проверяем отлаживаем и следим за системой создания бэкапов базы и очень ответственно подходим к процессу обновления конфигурации (делаем это не по сети, а желательно на сервере, по возможности сделав предварительно бэкап). Особенно если версия вашей 1С стала 8.2. Насколько я понял из статей в сети и превых двух дней работы с ней, что она более чувствительна и капризна, по сравнению 8.1 с которой таких проблем не было.
5а. Если конфигурация базы с которой вы будете копировать таблицу конфы — все-таки отличается, (не имея при этом отличий в метаданных, о чем я уже говорил), и где-то лежит ваш относительно свежий cf-файл с выгруженной конфой — накатываем его на ожившую базу. В противном случае Вам придется повторить все те отличия, которые были с копией конфигуратора. Так что еще раз хорошо подумайте и проанализируйте — что важнее — ваша работа по изменению конфигурации (и сколько времени вы на это потратите) или работа пользователей базы до момента последнего бэкапа. В моем случае это была работа 2-х программистов в течении 3-х часов против работы порядка 100 пользователей в течении 1.5 дней, так что выбор был очевиден.
З.Ы. Еще раз напомню? что данная функция восстановления является недокументированным 1С-овцами способом восстановления базы (в конкретном случае обрушения базы, произошедшего в процессе сохранения конфы) и все что вы делаете — вы делаете на свой страх и риск, но конкретно в моем случае других путей оживить базу с минимальной потерей существующей информации не было (лог файл потерли и самый свежий бэкап представлял потерю 1.5 дня работы порядка 100 пользователей), поэтому, как говорится мосты были сожжены )
З.Ы.Ы. Это моя первая публикация тут т.к. трусь на других 1С форумах, но нахожу этот ресурс одним из самых полезных в плане выложенных разработок и публикаций, поэтому не судите строго за много ЕСЛИ в данной публикации). Буду очень рад, если реально помог кому-нибудь с восстановлением порушенной базы ибо страшнее этого только ядерная война )
З.Ы.Ы.Ы. Спустя 3 недели проблема повторилась ) На этот раз на решение было потрачены какие-то секунды (если не учитывать время создания бэкапа), и даже пользователей не пришлось выгонять.
_____________________________________________________________________________________________________________
Сегодня прибежал коллега. Та же самая беда. Только база тестовая а не рабочая и сама база ему поскольку постольку — а вот конфигуратор ему важен. Неделю он краптел над ним ни разу не выгрузив в cf файл и не накатив изменения в рабочую базу. Ну что ж — почему бы не поковырятся уже с таблицей?! На этот раз все еще проще. Открываю SQL Managment Studio. Формирую запрос по таблице на поля с текущей датой изменения и временем когда у него вылетела база — результат дает 2 записи. Первая — Поле FileName = «commit» Ну что же — грохнуть эту запись — и у меня все получилось! Конфигуратор ожил и база опять работает. Что же нужно сделать?!
Итак в открытом окне SQL Managment Studio ищем нашу базу — открываем Таблицы, ищем в конце списка таблицу с конфой dbo.config на таблице — правую кнопку — Открыть таблицу. Далее в правом окне спускаемся в самой таблице вниз по алфавиту на поле где FileName = «commit». Встаем на эту запись — правую кнопку мыши — Удалить. В общем удаляем запись с двоичным файлом. Далее пробуем зайти в конфу. Ошибка та же самая первая появляется. Наверно не получилось?Ё Нажимаем Ок. И тут, прежде чем выдать как ранее 2-е сообщение о невозможности сохранить — компьютер задумался. Спустя секунд 30 — О ЧУДО! Конфигуратор открылся. Пробуем сохранить конфигуратор (предварительно сохранив cf файл). Конфигуратор сохраняется. Таким образом и волки сыты и овцы целы. Не уверен насчет полной работоспосбности базы после таких измывательств — так что посоветую сделать реструтуризацию и пересчет итогов уже потом вечером (предварительно конечно же сделав архив). Удачного востановления и положительных эмоций )
вылетел конфигуратор при обновлении , терь не могу ни в конф ни в предприятие !! |
Я |
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
- 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с сначала выходит диалог с ошибкой «При обновлении данных после последней реструктуризации произошла критическая ошибка. Повторить обновление».
Если попытаться обновить, бывает два варианта сценария
- все применяется корректно, но потребуется завершить работу пользователей для обновления
- обновление не проходит: выходит сообщение («Обнаружена незавершенная операция сохранения конфигурации«)
Причины и обстоятельства
Такие ошибки возникают обычно на старых версиях платформы. В настоящее они время проявляются очень редко (на 8.3 не встречалось ни разу).
Также замечу: в последней платформе 8.3.8 появилось долгожданное динамическое обновление в клиент-серверном режиме без перезапуска конфигуратора (ранее такое было только на файловых базах).
Можно долго говорить о том, что не надо пользоваться динамическим обновление, необходимо организовывать работу так, чтобы это происходило реже, но это документированный функционал платформы, соответственно он должен работать корректно.
Что же делать при такой ошибке?
- запомнить/записать точное время возникновения ошибки.
- сообщить всем о том, что ошибка известна, вы работаете над ее решением и база некоторое время работать не будет (далее игнорируете всех, кто не может вам помочь иначе вас затерроризируют вопросами)
- сделать полную копию базы данных
- развернуть(открыть) копию базы, где конфигурация соответствует составу реквизитов (они должны совпадать), код модулей и форм может отличаться (быть не актуальным)
- если есть отличия в реквизитах постараться «свести» конфигурации
Если копий нет, то в случае если конфигурация типовая и правки не затрагивают структуру данных, то разворачивайте типовую конфигурацию.
Далее, производите замещение конфигурации из «копии» в «исправляемую» базу
Для этого Запускаете SQL Management Studio и выполняете такой запрос:
delete from [ИмяИсправляемойБазы].[dbo].[Config] GO insert into [ИмяИсправляемойБазы].[dbo].[Config] SELECT [FileName] ,[Creation] ,[Modified] ,[Attributes] ,[DataSize] ,[BinaryData] FROM [КопияБазы].[dbo].[Config] GO
В 99% случаев он вам поможет (мне помогало 3 раза). Исправление занимало от 5 до 20 минут.
Далее восполняете пробелы в коде. Если конфигурация подключена к хранилищу, необходимо синхронизировать захваченные объекты (отпустить и захватить заново), внести правки.
Если версия файловая произведите тестирование утилитой «C:Program Files (x86)1cv88.*.*.*binchdbfl.exe».
При отсутствии конфигурации/копии:
- смотрите записи таблицы dbo.ConfigSave, при наличии — очищайте (пробуйте запустится)
- смотрите записи таблицы Config, на поле «FileName», если есть со значением «commit»,»dbStruFinal» или «dynamicCommit» — удаляйте
- либо в этой же таблице смотрите записи с именами подобными %_dynupdate_ % (здесь потребуется «по манипулировать» с датами и именами, но у меня не получалось)
Не помогло?
В остальных случаях придется поднимать и откатывать копии базы данных или транзакции (при полной модели восстановлении).
При небольшом документообороте может оказаться проще откатить базу на несколько минут назад — быстрее восстановить работоспособность (внести данные заново), чем поднимать другие копии.
Рекомендации
- Используйте полную модель восстановления
- Чаще делайте копии и базы, и конфигурации (в идеале: перед каждым обновлением)
- Используйте хранилище для разработки
- Держите рядом копию базы (это сэкономит время для восстановления)
- При подозрительных ошибках в момент обмена с хранилищем не обновляйте базу при работающих пользователях
В моем случае возникла ошибка snegopat-а при обмене с хранилищем, а затем такая же в момент обновления — с вытекающими проблемами.
Вся реклама — это хорошие новости.
При обновлении конфигурации 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