Ситуация, когда при обновлении или реструктуризации базы данных происходит сбой, является одной из самых критических для администратора или программиста 1С. Ошибка «Обнаружена незавершенная операция сохранения конфигурации. Для продолжения работы необходимо завершить операцию» фактически блокирует доступ как в режим предприятия, так и в конфигуратор. В этой статье мы подробно разберем, почему возникает эта проблема и какими методами можно вернуть базу в рабочее состояние.
Рассмотрим внутренние процессы платформы. Когда мы запускаем обновление конфигурации базы данных (особенно при изменении структуры таблиц), 1С выполняет транзакционную операцию. Процесс состоит из нескольких этапов: создание временных таблиц, перенос данных, переименование таблиц и, наконец, фиксация изменений. Для отслеживания прогресса платформа записывает в специальную системную таблицу CONFIG (или ConfigSave) маркеры — записи с именами commit, dbStruFinal или dbStruFinalNew.
Проанализируем ситуацию: если в момент записи этих маркеров происходит скачок напряжения, аварийное завершение процесса 1cv8.exe или сбой сетевого соединения (в случае файловой базы на сетевом ресурсе), маркер остается в базе. При следующем запуске платформа видит этот «флаг» и понимает, что прошлая операция не была завершена. Поскольку она не знает, на каком именно этапе произошел сбой, она блокирует вход, чтобы предотвратить окончательное разрушение данных.
Прежде чем мы разберем технические методы правки таблиц, выполним важнейшее действие — создадим копию файла базы данных. Любые манипуляции с утилитами Tool_1CD или HEX-редакторами могут быть необратимы. Просто скопируйте файл 1Cv8.1CD в отдельную папку. Это ваша «точка отката».
Перед тем как прибегать к «хирургическому» вмешательству, попробуем воспользоваться официальным средством от разработчиков 1С. Разберем порядок действий:
C:\Program Files\1cv8\номер_версии\bin\chdbfl.exe.1Cv8.1CD.Выясним причину, почему это помогает: утилита проверяет логическую и физическую целостность файла. В некоторых случаях она способна корректно закрыть незавершенную транзакцию или удалить поврежденные ссылки, что позволит зайти в конфигуратор.
Иногда ошибка может быть вызвана не только состоянием базы, но и локальными файлами. Проверим папку, в которой находится база данных. Если 1С закрыта, там не должно быть ничего, кроме самого файла 1Cv8.1CD и папки логов. Если мы видим файл 1Cv8.cfl, его необходимо удалить. Это файл блокировки конфигурации, который может «зависнуть» после сбоя.
Также проанализируем состояние кэша. Попробуем удалить базу из списка в стартере 1С и добавить её заново. Это принудительно создаст новую папку кэша, что исключит влияние старых временных данных на процесс запуска.
Если штатные средства не помогли, переходим к редактированию структуры базы. Для этого нам понадобится утилита Tool_1CD, позволяющая просматривать и редактировать таблицы файловой базы. Наша цель — найти и удалить записи-маркеры, которые мешают запуску.
Рассмотрим алгоритм действий в программе:
Tool_1CD.CONFIG (в некоторых версиях она может называться Config).FileName.commit и dbStruFinal.Если мы используем программный доступ к компонентам или специализированные скрипты для очистки, логика удаления будет выглядеть следующим образом:
// Пример логики поиска и удаления записей-маркеров
FileDB.OpenTable(0, "CONFIG");
FieldFileName = "FILENAME";
Рез = FileDB.MoveFirstRecord(0);
Пока Рез Цикл
Если НЕ FileDB.IsRecordDeleted(0) Тогда
FileName = FileDB.ReadSimpleValue(0, FieldFileName);
Если (FileName = "commit") ИЛИ (FileName = "dbStruFinal") Тогда
FileDB.DeleteRecord(0); // Удаляем запись, блокирующую базу
КонецЕсли;
КонецЕсли;
Рез = FileDB.MoveNextRecord(0);
КонецЦикла;
После удаления этих записей сохраним изменения и попробуем зайти в Конфигуратор. Если вход выполнен успешно, необходимо сразу выполнить команду Конфигурация -> Обновить конфигурацию базы данных (F7), чтобы платформа привела структуру в соответствие.
Это более тонкий метод, который мы разберем для случаев, когда специализированные утилиты не справляются. Суть метода заключается в изменении имени маркера прямо в двоичном коде файла. Платформа перестанет узнавать «зависшую» операцию и позволит зайти в конфигуратор.
Выполним следующие шаги:
dbStruFinal. Важно помнить, что в файле 1С данные хранятся в кодировке Unicode (UTF-16LE). Это значит, что между буквами будут нулевые байты.64 00 62 00 53 00 74 00 72 00 75 00 46 00 69 00 6E 00 61 00 6C.d на c.Важный момент: этот метод является «грязным» хаком. Он не исправляет структуру, а лишь убирает проверку. Сразу после входа обязательно нужно провести полноценное обновление (F7) или выгрузить информационную базу в .dt и загрузить обратно в новую чистую базу.
Хотя в обсуждении речь шла о файловой базе, проанализируем ситуацию и для серверного варианта, так как ошибка идентична. В SQL-варианте нам помогут прямые запросы к базе данных через SQL Management Studio.
Посмотрим на примеры запросов для очистки блокирующих таблиц:
-- Очистка таблицы временной конфигурации
DELETE FROM [Имя_Вашей_Базы].[dbo].[ConfigSave]
-- Если не помогло, можно попробовать подменить таблицу Config
-- из последней живой резервной копии (BaseCopy)
USE [Имя_Вашей_Базы]
DELETE FROM [dbo].[Config]
GO
INSERT INTO [Имя_Вашей_Базы].[dbo].[Config]
SELECT * FROM [BaseCopy].[dbo].[Config]
Внимание: прямое редактирование таблиц SQL крайне не рекомендуется без глубокого понимания структуры. Всегда делайте бэкап средствами SQL перед выполнением запросов DELETE.
Мы рассмотрели несколько способов спасения базы: от простых штатных средств до глубокого редактирования двоичных данных. Подведем итоги:
Проанализировав причины подобных сбоев, дадим главный совет: никогда не пренебрегайте резервным копированием перед обновлением, даже если вы просто добавляете «обычную обработку». Кроме того, для критически важных баз рекомендуется переход с файлового режима на клиент-серверный, так как он гораздо более устойчив к подобным транзакционным сбоям.