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

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

В свое время столкнулся с проблемой: при обновлении конфигурации из хранилища, произошел сбой, и закрылась 1С.

Как выяснилось позднее – произошло разрушение хранилища конфигурации и при обновлении конфигурации из хранилища слетела и конфигурация БД. Подобная ошибка возникала прежде при динамическом обновлении ИБ.

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

При следующем запуске конфигуратора вышла ошибка: «Внимание. При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?» при утвердительном ответе получаем сообщение: «Обнаружена незавершенная операция сохранения конфигурации. Для продолжения работы необходимо завершить операцию» после этого приложение закрывается.

При разборе данной проблемы было найдено несколько вариантов решения проблемы, каждое решение работает в разных случаях.

Вариант 1 (при наличии бэкапа SQL c копией с идентичной конфигурацией):

Разворачивается копия ИБ, и выполняется запрос следующей конструкции:

При этом пере заливается таблица в которой хранится конфигурация ИБ. Желательно после данной операции выполнить тестирование и исправление ИБ.

Вариант 2 (при отсутствии бэкапа):

К данному варианту обратились как к последней соломинке. Т.к. конфигурация была в стадии разработки и про бэкап немного позабыли понадеясь на хранилище.
В базе удаляются две записи из таблицы «Config» по значению в столбце «FileName» — dbStruFinal и commit

Выполняется следующий запрос:

Как ни странно база оживает.

Данная статья не подлежит комментированию, поскольку её автор ещё не является полноправным участником сообщества. Вы сможете связаться с автором только после того, как он получит приглашение от кого-либо из участников сообщества. До этого момента его username будет скрыт псевдонимом.

Данная ошибка возникает в основном на платформе 8.2, на платформе 8.3 мы не встречали ее ни разу. Кстати в релизе платформы 8.3.8 уже реализована возможность динамического безболезненного обновления, если вы работаете в клиент серверном режиме. Для того, чтобы исправить ситуацию, нам необходимо исправить таблицу ‘config’ в базе данных SQL.

Читайте также:  Как вставить батарею в лягушку правильно

Есть несколько способов это сделать:

Восстановить из резервной копии (в данном случае все ранее внесенные изменения в конфигурацию не сохраняться). Данную манипуляцию вы можете провернуть там же, где и создается данная копия:

Если же для вас критично сохранить все изменения и наработки в вашей 1С, тогда попытаемся исправить нашу ошибку другим, более сложным способом:

Все объекты, которые вы изменяли в конфигурации хранятся в таблице configsave. При обновлении происходит сначала заполнение таблицы configsave, после чего данные переносятся в таблицу config, стираясь с предыдущего места. Вы можете воспользоваться возможностью скопировать таблицу config из идентичной базы в неработающую или, как вариант, удалить все найденные изменения.

Для этого вам необходимо выполнить два запроса:

1. delete from config where FileName = ‘commit’

2. delete from config where FileName = ‘dbStruFinal’

3. delete from config where FileName = ‘dynamicCommit’

Кстати на многих форумах рекомендуют также выполнить запрос delete from config where FileName = ‘dbStruFinal’. Однако это делать не обязательно, так как программа почистит их при запуске.

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

При запуске 1с сначала выходит диалог с ошибкой «При обновлении данных после последней реструктуризации произошла критическая ошибка. Повторить обновление».

Если попытаться обновить, бывает два варианта сценария

  • все применяется корректно, но потребуется завершить работу пользователей для обновления
  • обновление не проходит: выходит сообщение («Обнаружена незавершенная операция сохранения конфигурации«)

Причины и обстоятельства

Такие ошибки возникают обычно на старых версиях платформы. В настоящее они время проявляются очень редко (на 8.3 не встречалось ни разу).

Также замечу: в последней платформе 8.3.8 появилось долгожданное динамическое обновление в клиент-серверном режиме без перезапуска конфигуратора (ранее такое было только на файловых базах).

Читайте также:  Какой комментарий можно написать другу под фото

Можно долго говорить о том, что не надо пользоваться динамическим обновление, необходимо организовывать работу так, чтобы это происходило реже, но это документированный функционал платформы, соответственно он должен работать корректно.

Что же делать при такой ошибке?

  • запомнить/записать точное время возникновения ошибки.
  • сообщить всем о том, что ошибка известна, вы работаете над ее решением и база некоторое время работать не будет (далее игнорируете всех, кто не может вам помочь иначе вас затерроризируют вопросами)
  • сделать полную копию базы данных
  • развернуть(открыть) копию базы, где конфигурация соответствует составу реквизитов (они должны совпадать), код модулей и форм может отличаться (быть не актуальным)
  • если есть отличия в реквизитах постараться «свести» конфигурации

Если копий нет, то в случае если конфигурация типовая и правки не затрагивают структуру данных, то разворачивайте типовую конфигурацию.

Далее, производите замещение конфигурации из «копии» в «исправляемую» базу

Для этого Запускаете SQL Management Studio и выполняете такой запрос:

В 99% случаев он вам поможет (мне помогало 3 раза). Исправление занимало от 5 до 20 минут.

Далее восполняете пробелы в коде. Если конфигурация подключена к хранилищу, необходимо синхронизировать захваченные объекты (отпустить и захватить заново), внести правки.

Если версия файловая произведите тестирование утилитой «C:Program Files (x86)1cv88.*.*.*inchdbfl.exe».

При отсутствии конфигурации/копии:

  • смотрите записи таблицы dbo.ConfigSave, при наличии — очищайте (пробуйте запустится)
  • смотрите записи таблицы Config, на поле «FileName», если есть со значением «commit»,»dbStruFinal» или «dynamicCommit» — удаляйте
  • либо в этой же таблице смотрите записи с именами подобными %_dynupdate_ % (здесь потребуется «по манипулировать» с датами и именами, но у меня не получалось)

Не помогло?

В остальных случаях придется поднимать и откатывать копии базы данных или транзакции (при полной модели восстановлении).

Читайте также:  Epson l210 заправка чернил

При небольшом документообороте может оказаться проще откатить базу на несколько минут назад — быстрее восстановить работоспособность (внести данные заново), чем поднимать другие копии.

Рекомендации

  • Используйте полную модель восстановления
  • Чаще делайте копии и базы, и конфигурации (в идеале: перед каждым обновлением)
  • Используйте хранилище для разработки
  • Держите рядом копию базы (это сэкономит время для восстановления)
  • При подозрительных ошибках в момент обмена с хранилищем не обновляйте базу при работающих пользователях

В моем случае возникла ошибка snegopat-а при обмене с хранилищем, а затем такая же в момент обновления — с вытекающими проблемами.

Реклама всегда менее актуальна, чем думают ее создатели.

Ссылка на основную публикацию
Обзор флагманов смартфонов 2018
Флагманским смартфоном или просто флагманом принято называть самое лучшее устройство производителя, в котором собраны все самые лучшие и новые технологии....
Нет инженерного меню на андроид
Мобильные гаджеты на платформе Android не защищены от ошибок, сбоев и программных поломок. Большое количество неисправностей решается с помощью встроенного...
Нет кнопки персонализация windows 7
Одним из самых главных преимуществ пользовательского интерфейса Windows является легкость подстройки его внешнего вида под собственные вкусы. И хотя внести...
Обзор эллиптических тренажеров для дома
*Обзор лучших по мнению редакции expertology.ru. О критериях отбора. Данный материал носит субъективный характер, не является рекламой и не служит...
Adblock detector