Что делать при ошибке структуры базы данных 1С после обновления?

В процессе обновления конфигурации или применения динамического обновления программисты и администраторы иногда сталкиваются с ситуацией, когда платформа начинает «ругаться» на отсутствие или наличие несуществующего поля в таблицах базы данных MS SQL Server (например, колонки Fld38683 в табличной части Document229.VT2818). Попытки вручную удалить или добавить эту колонку средствами SQL Server Management Studio обычно только усугубляют ситуацию. Разберем по шагам, почему возникает эта ошибка и как корректно восстановить работоспособность информационной базы.

Почему нельзя редактировать колонки напрямую в MS SQL Server

Платформа 1С:Предприятие хранит информацию о структуре данных сразу в нескольких местах:

1. Физические таблицы СУБД MS SQL Server: таблицы документов, справочников и их табличных частей (например, Document229 и VT2818).
2. Служебная таблица Config (или Params): содержит упакованную структуру метаданных (файл DBNames), согласно которой платформа строит SQL-запросы.

Когда вы удаляете колонку через SQL-запрос ALTER TABLE ... DROP COLUMN, физическое поле исчезает из MS SQL, но запись о нем остается в бинарных данных конфигурации базы данных. При выполнении любой операции 1С продолжает формировать SQL-запросы с упоминанием «удаленного» поля, что приводит к критической ошибке СУБД. Именно поэтому ручные правки структуры базы данных в SQL Server категорически не рекомендуются.

Причины возникновения ошибки

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

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

Способы решения проблемы

Способ 1. Полная очистка кэша сервера 1С и клиентов

Часто проблема кроется в том, что рабочий процесс сервера 1С (rphost) удерживает в памяти устаревшую схему метаданных. Разберем порядок действий для очистки сеансового кэша:

1. Остановите службу агента сервера 1С:Предприятия.
2. Удалите кэш рабочих процессов в каталоге сервера приложений (папки вида snacc* и временные файлы сеансов).
3. Очистите кэш на клиентском компьютере (удалите папки из %LocalAppData%\1C\1cv8 и %AppData%\1C\1cv8).
4. Запустите службу агента 1С и проверьте воспроизводимость ошибки.

Способ 2. Восстановление конфигурации базы данных

Если конфигуратор открывается, попробуем сбросить незавершенные изменения и вернуть конфигурацию к заведомо исправному состоянию:

1. Откройте Конфигуратор.
2. В меню выберите Конфигурация -> Конфигурация базы данных -> Вернуться к конфигурации БД. Это сбросит редактируемую конфигурацию из таблицы ConfigSave.
3. Если ошибка сохраняется, загрузите исходный файл конфигурации (.cf), с которого производилось обновление, через меню Конфигурация -> Загрузить конфигурацию из файла... и выполните обновление базы данных (клавиша F7).

Способ 3. Очистка незавершенных транзакций в таблице Config

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

DELETE FROM Config WHERE FileName = 'commit';
DELETE FROM Config WHERE FileName = 'dbStruFinal';

Важно: Выполняйте данные SQL-запросы только после создания полного бэкапа базы данных MS SQL. После выполнения запросов обязательно перезапустите службу сервера 1С.

Способ 4. Тестирование и исправление информационной базы

Если конфигуратор успешно запускается, разберем выполнение штатной процедуры проверки целостности:

1. Запустите Конфигуратор в монопольном режиме.
2. Перейдите в меню Администрирование -> Тестирование и исправление...
3. Установите флаги Проверка целостности информационной базы и Реструктуризация таблиц информационной базы.
4. Запустите процесс и дождитесь его завершения.

Способ 5. Использование резервной копии с переносом данных

Если структура таблицы повреждена безвозвратно, рассмотрим самый надежный вариант сохранения накопленных данных:

1. Разверните имеющийся рабочий бэкап базы данных (например, трехчасовой давности) в отдельную информационную базу.
2. Загрузите в развернутый бэкап правильный файл конфигурации (.cf).
3. С помощью обработки Универсальный обмен данными в формате XML или механизмов интеграции перенесите документы и справочники, созданные за период с момента снятия бэкапа до сбоя.