← На главную

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

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

Выясним причины повреждения метаданных поставщика

Проанализируем основные факторы, которые приводят к повреждению бинарных данных конфигурации поставщика в СУБД:

1. Аварийное прерывание транзакции: сбой связи между сервером 1С и СУБД, нехватка дискового пространства или аварийная перезагрузка службы ragent в момент сохранения конфигурации. В результате в системных таблицах остаются неполные или несогласованные бинарные потоки (BLOB).
2. Повреждение серверного кэша метаданных: файлы в каталогах кэша кластера серверов 1С (каталоги snccntx и reg_XXXX) могут быть повреждены. При обращении к метаданным сервер считывает поврежденный кэш и блокирует операцию.
3. Ограничения каталога временных файлов: нехватка свободного места в каталоге %TEMP% (Windows) или /tmp (Linux) для учетной записи службы 1C:Enterprise Server, либо отсутствие необходимых прав на запись при распаковке объемных файлов поставки.

Шаг 1. Первичная диагностика и очистка кэша

Прежде чем вмешиваться в таблицы базы данных на уровне СУБД, обязательно выполним базовые регламентные действия. Все манипуляции проводим исключительно на предварительно созданной резервной копии базы данных.

1. Полностью останавливаем службу сервера 1C:Enterprise Server.
2. Очищаем локальный кэш конфигуратора и тонкого клиента на рабочем месте разработчика (каталоги %LOCALAPPDATA%\1C\1cv8 и %APPDATA%\1C\1cv8).
3. Очищаем серверный кэш сеансов и контекстов метаданных на сервере 1С в рабочем каталоге кластера.
4. Проверяем наличие достаточного свободного места на дисках с каталогами временных файлов и базой данных.
5. Запускаем службу сервера 1С и проверяем, сохраняется ли ошибка при открытии конфигуратора.

Шаг 2. Очистка незавершенных транзакций в таблице ConfigSave

Если в процессе предыдущего неудачного обновления в базе зависли временные метаданные, конфигуратор будет постоянно обращаться к некорректным потокам. В клиент-серверном варианте базы данных состояние несохраненных изменений конфигурации хранится в системной таблице dbo.ConfigSave.

Рассмотрим порядок очистки через консоль СУБД SQL:

1. Завершаем все активные сеансы пользователей и закрываем Конфигуратор.
2. Выполняем SQL-запрос для очистки таблицы несохраненной конфигурации: DELETE FROM dbo.ConfigSave;
3. Перезапускаем службу сервера 1С.
4. Открываем Конфигуратор и проверяем возможность работы с конфигурацией поставщика.

Шаг 3. Восстановление конфигурации поставщика через SQL

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

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

Рассмотрим алгоритм действий по шагам:

1. Разворачиваем архивную копию базы данных на SQL-сервере.
2. В копии накатываем необходимые релизы конфигурации поставщика штатным способом до той версии, которая должна быть в рабочей базе.
3. Убеждаемся, что в обновленной копии конфигурация поставщика открывается и сохраняется без ошибок.
4. В рабочей базе через SQL очищаем битые записи поставщика в таблице Config (записи, содержащие идентификаторы поставки и GUID файлов поставщика) либо полностью заменяем таблицу Config из проверенной копии.

Шаг 4. Снятие с поддержки и повторная постановка через сравнение/объединение

Если прямое восстановление через SQL нежелательно из-за расхождения структуры основной конфигурации, применим штатный метод переподключения конфигурации поставщика:

1. Удаляем битую конфигурацию поставщика. Если Конфигуратор не позволяет выполнить Конфигурация — Поддержка — Настройка поддержки — Снять с поддержки, удаляем записи метаданных поставщика напрямую из таблицы Config в SQL.
2. После очистки открываем базу в Конфигураторе: конфигурация должна определяться как полностью снятая с поддержки.
3. Берем файл поставки (дистрибутив или чистый .cf) в точности того релиза, который был установлен в качестве конфигурации поставщика.
4. Выполняем команду меню Конфигурация — Сравнить, объединить с конфигурацией из файла... и выбираем наш файл .cf.
5. В появившемся диалоге с вопросом «Поставить конфигурацию на поддержку?» отвечаем «Да».
6. В окне сравнения и объединения снимаем флажки со всех объектов, чтобы не затереть доработки рабочей базы, сохраняя при этом правила поддержки для типовых объектов.
7. Применяем изменения по кнопке Выполнить и обновляем конфигурацию базы данных (клавиша F7).

Шаг 5. Альтернативный метод: выгрузка и загрузка через XML-файлы

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

1. Выгружаем основную конфигурацию в каталог файлов через командную строку: 1cv8.exe DESIGNER /S "Сервер/База" /DumpConfigToFiles "C:\ConfigDump"
2. Создаем чистую базу данных и загружаем в нее структуру метаданных из полученного каталога: 1cv8.exe DESIGNER /S "Сервер/НоваяБаза" /LoadConfigFromFiles "C:\ConfigDump"
3. В результате такой выгрузки и загрузки все невалидные потоки конфигурации поставщика отсекаются, а полученная конфигурация ставится на поддержку заново с чистого файла поставщика.

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