При обновлении данных, после последней реструктуризации, произошла критическая ошибка. Повторить обновление?
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 |
Собственно это решение было найдено в интернете и протестировано в реальных условиях и показало результат. Огромное спасибо тому кто потратил время, на изучение этого вопроса и поделился этой информацией.
31.05.13 — 10:24
Итак, деномическое обновление базы прошло не совсем успешно, что-то пошло не так. Если пробовать запускать конфигуратор пишет «Внимание!!! При обновлении данных, после последней реструктуризации, произошла критическая ошибка. Повторить обновление?» Если нажать да — зависал, через пару часов я процесс отрубил. Пользователи как работали так и работают. Но если 1ску закрыть, то база не открывается, намекает что недообновилась и надо бы зайти в конфигуратор. База на скуле, 70 Гб. Архив есть только ночной, документов 100 пользователей уже намолотили. Погуглил, нашел пару статеек. Основная идея выглядит так:
Use РабочаяБаза
go
Delete From [DBO].[Config]
go
потом
insert into [РабочаяБаза].[Dbo].[Config] select * from [Копия].[Dbo].[Config]
go
Типа если структура метаданных не менялась, то все будет норм… Пока что делаю архив текущего состояния, пользователи дальше работают, часика через два начну тренироваться на копии… Так же предлагают альтернативный скрипт, который не очень понимаю что делает:
GO
DROP TABLE [ПОЛОМАНАЯ_БАЗА].[dbo].[Config]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [ПОЛОМАНАЯ_БАЗА].[dbo].[Config](
[FileName] [nvarchar](128) NOT NULL,
[Creation] [datetime] NOT NULL,
[Modified] [datetime] NOT NULL,
[Attributes] [smallint] NOT NULL,
[DataSize] [int] NOT NULL,
[BinaryData] [image] NOT NULL,
PRIMARY KEY CLUSTERED
(
[FileName] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
INSERT INTO [ПОЛОМАНАЯ_БАЗА].[dbo].[Config]
SELECT * FROM [БЭКАПНАЯ_БАЗА].[dbo].[Config]
GO
Кто-нть боролся с таким косяком? Что таки делает второй скрипт дополнительно и чем лучше пользоваться первым или вторым?
5 — 31.05.13 — 10:30
З.ы. 2-й тоже самое, но создаётся заново таблица конфиг с нуля, вот и разница всё. Это если сама таблица повредилась, а не данные в ней
Внимание!!! При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?
Опубликовано: 16.02.2018 /
Переезжали мы на новый сервер. На нем SQL и 1C. В сравнении со старыми был намного круче. И тест Гилева это тоже подтвердил: против 10-15 на старых серверах выдавал 39. Поэтому мы сразу после покупки перенесли базу и начали работу.
Но в какой-то момент что-то пошло не так — пользователи стали жаловаться на медленную работу. Произвели определенные настройки сервера и служб (какие — тема отдельного поста) и решили перезагрузить сервер, благо скорость перезагрузки — 2 минуты (на других серверах до 10 доходило). После этого при входе в 1С получаем следующее сообщение:
«Внимание!!! При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?» «Да, Нет»
После нажатия кнопки «Да» появляется следующее:
«Обнаружена незавершенная операция сохранения конфигурации. Для продолжения работы необходимо завершить операцию.»
Первое, что решил сделать — CHECKDB на в Managment Studio — после 2х часов ожидания (база 500 ГБ) — все ОК.
На просторах сети нашел информацию, что такая же ошибка бывает при динамическом обновлении.
Решения, предложенные в сети сходу не помогли, но вкупе с другими действия дали результат. Итак, что я делал:
Решение:
- То, чего не хватало для решений из сети:
sp_configure ‘allow updates’, 1
reconfigure with override
go
2. Переводим базу в режим восстановления
alter database [db_name] set EMERGENCY, SINGLE_USER
3. Выполняем тестирование базы:
dbcc checkdb(‘db_name’, REPAIR_ALLOW_DATA_LOSS )
4. Выводим базу из режима восстановления:
alter database [db_name] set ONLINE, MULTI_USER
5. В принципе, если уверены что с самой базой все ок, то можно не делать 2-4 пункты. Далее выполняем два запроса в профайлере SQL:
delete from config where FileName = ‘commit’
delete from config where FileName = ‘ dbStruFinal’Эти записи и отвечают за динамическое обновление — можно не бояться их удалять.
В рабочих версиях баз запросы:
select * from Config WHERE FileName = ‘commit’
select * from Config WHERE FileName = ‘dbStruFinal’
будут пустые.
6. возвращаем настройки:
sp_configure ‘allow updates’, 0
go
7. После этого удалось запустить конфигуратор и база заработала.
Также база может заработать после удаления первого флага.
Еще из решений, которые есть в сети, полная замена таблицы Config.
Что у меня использовалось:
Платформа 1С: 1С:Предприятие 8.3 (8.3.10.2466)
SQL: Microsoft SQL Server 2008 R2 Standard Edition (64-bit) 10.50.6220.0
Также обратил внимание, что проблема повторяется на всех версиях платформ и SQL.
Всем удачи с решением таких проблем. Если есть трудности, обращайтесь, помогу.
p.s. бекап был, но терять даже несколько часов работы не очень хотелось
Пару раз уже случалось увидеть такую надпись при обновлений конфигурации 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С произошел сбой, программа завершила свою работу по ошибке. Затем, при попытке зайты в конфигуратор, стало выдаваться предупреждение: «При обновлении данных после последней реструктуризации произошла критическая ошибка. Повторить обновление?». Если ответить «Нет», то программа просто завершает свою работу, в случае же положительного ответа выводится сообщение «Обнаружена незавершенная операция сохранения конфигурации. Для продолжения работы необходимо завершить операцию.» и программа также закрывается.
Еще ошибка может быть следующая: Нарушена целостность структуры конфигурации. В этом случае, в первую очередь, нужно попробовать почистить кэш 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
Обнаружена незавершенная операция сохранения конфигурации
Ошибка возникает после динамического обновления.
При запуске 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С. После чего наотрез отказалась входить в базу. При этом в конфигураторе выдавалось сообщение «Внимание!!! При обновлении данных, после последней реструктуризации, произошла критическая ошибка. Повторить обновление?» Потом выходило сообщение «Обнаружена незавершённая операция сохранения конфигурации. Для продолжения необходимо завершить операцию». Горела кнопка Ок — на этом работоспособность конфигуратора и базы заканчивалась.
Предистория.
Два дня назад осуществили переход с 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 файл). Конфигуратор сохраняется. Таким образом и волки сыты и овцы целы. Не уверен насчет полной работоспосбности базы после таких измывательств — так что посоветую сделать реструтуризацию и пересчет итогов уже потом вечером (предварительно конечно же сделав архив). Удачного востановления и положительных эмоций )