Обнаружена незавершенная операция сохранения конфигурации

Ошибка возникает после динамического обновления.

При запуске 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 правильных сонетов, чем хорошее рекламное объявление.

— Олдос Хаксли
Ошибки 1С
Предыдущая запись
Ошибочное поведение обработок заполнения табличной части
Следующая запись
Указано неверное поле для ввода по строке: Код

5 комментариев.

  • Дмтрий
    03.08.2017 16:40

    Спасибо огромное за статью. Данная статья оперативно помогла решить проблему.
    Кстати версия платформы: 8.3.9.1850, т.е. к сожалению платформа 8.3 тоже имеет такой косяк

  • Генрих
    12.08.2017 17:25

    Спасибо автору, помогло

  • Александр
    13.10.2017 08:28

    Спасибо, помогли следующие команды:
    delete from config where FileName = ‘commit’
    delete from config where FileName = ‘dbStruFinal’

  • Сергей
    19.10.2017 18:32

    На платформе 8.3 помог переброс таблицы Config из восстановленной копии. Спасибо автору за статью.

  • WebMaster
    02.11.2017 05:41

    Вряд ли связано с версией 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’

Обсуждение закрыто.