Как исправить ошибку SDBL о несоответствии типов при обновлении 1С:ERP?

При обновлении тяжелых конфигураций, таких как 1С:ERP Управление предприятием, специалисты часто сталкиваются с низкоуровневыми ошибками уровня SDBL (Simple Data Base Layer). Одна из самых неприятных — сообщение о несоответствии типа (например, ожидается тип 21, а в базе фигурирует поле Fld...). Ситуация осложняется тем, что стандартные средства, такие как Тестирование и исправление (ТиИ) или выгрузка/загрузка .dt, зачастую не приносят результата. В этой статье мы подробно разберем, как диагностировать и устранить эту проблему совместными усилиями системного администратора и разработчика.

Разбор причины ошибки: что означает тип 21?

Прежде всего, проанализируем природу ошибки. В архитектуре 1С код 21 во внутреннем представлении SDBL часто указывает на несоответствие типов, связанных с Перечислениями (Enums) или ссылочными данными системных таблиц. Ошибка возникает, когда логическое описание объекта в метаданных (хранящееся в таблице Config) не совпадает с физической структурой колонок в Microsoft SQL Server. Поле Fld622287 может физически существовать в базе, но иметь тип, который 1С больше не считает легитимным для данного объекта метаданных.

Шаг 1. Идентификация проблемной таблицы через SQL Profiler

Если стандартная обработка "Структура хранения БД" не находит поле по имени, нам необходимо выяснить, к какой таблице SQL оно относится. Для этого выполним следующие действия:

1. Запустим SQL Server Profiler.
2. Настроим фильтр по тексту (TextData), указав имя проблемного поля (например, Fld622287).
3. Повторим действие в 1С, вызывающее ошибку.
4. В логах профайлера найдем запрос вида SELECT... FROM _InfoRg21... или ALTER TABLE.... Это позволит точно определить имя физической таблицы в SQL.

Зная имя таблицы (например, _InfoRg12345), мы можем сопоставить его с объектом 1С, используя простой запрос к самой базе или специальную обработку "Просмотр структуры БД".

Шаг 2. Принудительная реструктуризация через расширения

Один из самых эффективных и быстрых способов заставить платформу 1С пересчитать структуру таблицы без удаления данных — использование механизма расширений. Рассмотрим этот метод пошагово:

1. Выясним, какому объекту метаданных принадлежит сбойное поле (допустим, это РегистрСведений.ЦеныНоменклатуры).
2. Создадим новое Расширение конфигурации.
3. Добавим в это расширение наш проблемный объект (регистр).
4. В расширении добавим этому объекту новый реквизит любого типа (например, Реквизит_Тест с типом Число).
5. Применим изменения в базе данных. В этот момент 1С инициирует процедуру реструктуризации (ALTER TABLE в SQL), что часто исправляет "залипшие" типы данных.
6. После успешного обновления удалим расширение или только созданный реквизит и снова обновим базу.

Этот метод заставляет систему заново сопоставить поля в Config и физической таблице SQL.

Шаг 3. Очистка служебных таблиц конфигурации в SQL

Иногда ошибка вызвана тем, что в служебных таблицах SQL остались записи о незавершенных или ошибочных изменениях. Мы можем попробовать очистить таблицы, отвечающие за регистрацию изменений конфигурации. Рассмотрим выполнение следующих команд в SQL Server Management Studio (SSMS):

DELETE FROM _ConfigChngR;
DELETE FROM _ConfigChngR_ExtProps;

Важно: Перед выполнением любых прямых запросов к БД обязательно создайте резервную копию! Также стоит попробовать очистить таблицу ConfigSave, если база находится в состоянии "конфигурация базы данных не соответствует основной конфигурации" и не дает обновиться:

DELETE FROM ConfigSave;

Шаг 4. Очистка серверного кэша и сеансовых данных

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

1. Остановим службу 1C:Enterprise Server.
2. Перейдем в каталог сеансовых данных (обычно это C:\Program Files\1cv8\srvinfo\reg_1541\...).
3. Удалим содержимое папки snccntx. Там хранятся данные сеансов и описания структур, которые могут блокировать корректную работу SDBL.
4. Запустим службу и проверим результат.

Шаг 5. Работа с "Историей данных" (Data History)

В конфигурации ERP активно используется механизм Истории данных. При обновлении структуры объекта метаданные истории могут конфликтовать с новыми типами. Выясним, не в этом ли причина:

1. Зайдем в раздел "Администрирование" — "Обслуживание" — "Управление историей данных".
2. Найдем объект, на который ругается система.
3. Попробуем временно отключить для него историю или нажать кнопку "Обновить".
4. Если ошибка сохраняется, можно попробовать полностью очистить историю данных для этого конкретного объекта.

Шаг 6. Использование параметров запуска для исправления метаданных

Существуют "глубокие" методы проверки, которые запускаются через командную строку. Рассмотрим вариант запуска платформы с ключом исправления информационной базы:

"C:\Program Files\1cv8\current\bin\1cv8.exe" DESIGNER /F "ПутьКБазе" /N "Логин" /P "Пароль" /IBCheckAndRepair -Rebuild

Параметр /IBCheckAndRepair с флагом -Rebuild инициирует пересчет внутренних идентификаторов и может устранить логические несоответствия в системных таблицах описания типов.

Шаг 7. Проверка логической целостности на стороне SQL

Если ни один из методов не помог, проанализируем ситуацию на уровне страниц данных SQL. Иногда "несоответствие типа" — это лишь следствие повреждения данных. Выполним команду проверки базы:

DBCC CHECKDB ('ИмяВашейБазы') WITH NO_INFOMSGS, ALL_ERRORMSGS;

Если команда вернет ошибки целостности, проблему нужно решать средствами восстановления SQL Server (например, через REPAIR_ALLOW_DATA_LOSS, но это крайний случай).

Резюме: Ошибка SDBL типа 21 чаще всего лечится принудительной реструктуризацией через расширение или очисткой серверного кэша. Если эти методы не помогают, следует переходить к анализу через SQL Profiler и очистке системных таблиц _ConfigChngR.