Ошибка возникает после динамического обновления.
При запуске 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)\1cv8\8.*.*.*\bin\chdbfl.exe”.
При отсутствии конфигурации/копии:
- смотрите записи таблицы dbo.ConfigSave, при наличии – очищайте (пробуйте запустится)
- смотрите записи таблицы Config, на поле “FileName”, если есть со значением “commit”,”dbStruFinal” или “dynamicCommit” – удаляйте
- либо в этой же таблице смотрите записи с именами подобными %_dynupdate_ % (здесь потребуется “по манипулировать” с датами и именами, но у меня не получалось)
Не помогло?
В остальных случаях придется поднимать и откатывать копии базы данных или транзакции (при полной модели восстановлении).
При небольшом документообороте может оказаться проще откатить базу на несколько минут назад – быстрее восстановить работоспособность (внести данные заново), чем поднимать другие копии.
Рекомендации
- Используйте полную модель восстановления
- Чаще делайте копии и базы, и конфигурации (в идеале: перед каждым обновлением)
- Используйте хранилище для разработки
- Держите рядом копию базы (это сэкономит время для восстановления)
- При подозрительных ошибках в момент обмена с хранилищем не обновляйте базу при работающих пользователях
В моем случае возникла ошибка snegopat-а при обмене с хранилищем, а затем такая же в момент обновления – с вытекающими проблемами.
Легче сочинить 10 правильных сонетов, чем хорошее рекламное объявление.
5 комментариев.
Спасибо огромное за статью. Данная статья оперативно помогла решить проблему.
Кстати версия платформы: 8.3.9.1850, т.е. к сожалению платформа 8.3 тоже имеет такой косяк
Спасибо автору, помогло
Спасибо, помогли следующие команды:
delete from config where FileName = ‘commit’
delete from config where FileName = ‘dbStruFinal’
На платформе 8.3 помог переброс таблицы Config из восстановленной копии. Спасибо автору за статью.
Вряд ли связано с версией SQL, появляется и на 2008 и на 2012. Обычно, в случае активного пользования динамическим обновлением за день (не в первый раз за день).
Последний раз помогло удаление строк именами dynamicCommit,commit,dbStruFinal из таблицы config, день работы был спасен (копия была только ночная)
Запрос вида:
delete from config where FileName = ‘commit’
delete from config where FileName = ‘dynamicCommit’
delete from config where FileName = ‘dbStruFinal’