Configsave ошибка обновления

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

Еще ошибка может быть следующая: Нарушена целостность структуры конфигурации. В этом случае, в первую очередь, нужно попробовать почистить кэш 1С. Если не поможет, то читаем дальше.

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

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

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

1. Если в таблице configsave есть данные, то таблицу нужно очистить: delete from configsave
2. delete from config where FileName = ‘commit’
3. delete from config where FileName = ‘dynamicCommit’
4. 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

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

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

Вариант 1

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

Вариант 2

Если же для вас критично сохранить все изменения и наработки в вашей 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» после падения, которое произошло во время обновления конфигурации. Причем это было дважды и методы примененные при восстановлении тоже были разными (скоро узнаете почему). В данной статье я хочу рассказать о тех способах, которыми я воспользовался.

Все способы рассматриваемые в статье относятся к серверному варианту работу «1С предприятие 8», используемое СУБД — MS SQL 2005.

Случай №1.

При обновлении конфигурации была выдана ошибка «Конфликт блокировок», конфигуратор был закрыт. При повторной попытке входа в конфигуратор появилась ошибка: Внимание!!! При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?» «Да, Нет»

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

Поиски на просторах интернета выдали следующий способ. В таблице Config нашей базы данные необходимо удалить строки где поле FileName = commit или FileName = dbStruFinal или FileName=DynamicallyUpdated (для 8.3) или FileName=dynamicCommit (8.3), а также очистить таблицу ConfigSave. Поясню за что отвечают данные таблицы: Config — в данной таблице хранится конфигурация базы данных, ConfigSave — в данной таблице хранится рабочая конфигурация, т.е. до нажатия кнопки F7 в конфигураторе.

Открываем SQL Serger Managment Studio и открываем окно запросов по кнопке «New Query» открывает окно запросов.

В окне запросов пишем запросы и выполняем их:

1. delete from [ИмяНашейБазы].[dbo].[Config] where FileName = ‘commit’
2. delete from [ИмяНашейБазы].[dbo].[Config] where FileName = ‘dbStruFinal’
3. delete from [ИмяНашейБазы].[dbo].[Config] where FileName = ‘DynamicallyUpdated’ (для версии 8.3)
4. delete from [ИмяНашейБазы].[dbo].[Config] where FileName = ‘dynamicCommit’ (для версии 8.3)
5. delete from [ИмяНашейБазы].[dbo].[ConfigSave] 

После выполнения данных запросов, конфигуратор запустился без проблем.

Случай №2

Причина ошибки входа в конфигуратор такая же как и в первом случае: конфликт блокировок при обновлении конфигурации.

Удаление строк в таблице Config и очистка таблицы ConfigSave помогло частично: конфигуратор открывался, но в предприятии не работали управляемые формы.

В данном случае приходило в голову 2 пути развития:

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

Для решения проблемы был выбран 2-ой вариант. Далее пошагово расскажу что делал.

1. Открываем SQL Serger Managment Studio и создаем произвольную базу, например Perenos. В этой базе создаем таблицу Config. Кто не знает sql для переноса данных из одной таблицы в другую, то у MS SQL есть замечательный сервис «SQL Server import and Export Wizard«. С помощью данного сервиса можно легко переносить данные из одной базу в другую. Чтобы запустить данный сервис необходимо нажать клавиши «ctrl+r» и в окне диалога написать команду «dtswizard«.
   
2. Переносим с помощью сервиса dtswizard данные таблицы Config нашей базы в таблицу Config базы Perenos.
3. Очищаем таблицу Config в нашей базе с помощью запроса delete from [ИмяНашейБазы].[dbo].[Config]
4. На сервере, где находится распределенная база запускаем сервис dtswizard и переносим данные из таблицы Config в такую же таблицу только в нашей базе.

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

Популярность: 29%

Запись опубликована в рубрике Настройка и оптимизация с метками восстановление. Добавьте в закладки постоянную ссылку.