Ошибка SDBL «Поле не найдено» в 1С — причины и решение

Ошибка SDBL «Поле не найдено» в 1С после обновления конфигурации или платформы. Реструктуризация таблиц через Конфигуратор, сравнение метаданных и SQL, откат на резервную копию.

Ошибка SDBL «Поле не найдено» в 1С:Предприятие 8.3 возникает после обновления конфигурации, динамического обновления или смены релиза платформы. Платформа видит поле в метаданных, но в физической структуре БД (SQL-таблице или dbf-файле) этого поля нет — либо ситуация обратная. Сценарий типичен после нештатного завершения реструктуризации и неполной выгрузки/загрузки cf.

Что означает эта ошибка

SDBL (Storage Database Language) — внутренний язык 1С для работы с хранилищем данных. Он транслируется в SQL (для клиент-серверных баз) или в команды файлового движка (для файловых баз). Если структура таблиц расходится с описанием реквизитов в конфигурации — SDBL не может построить запрос и завершается ошибкой «Поле не найдено».

Расхождение возникает, когда обновление прерывается на этапе реструктуризации: метаданные обновились, а физические таблицы — нет. После такого сбоя база может открываться, но первое же обращение к проблемному объекту приведёт к ошибке.

Ошибка SDBL:
Поле не найдено «Reference.Контрагенты.ИНН» (pos=125)

по причине:
Поле не найдено «_Reference45_IDRRef»

Появляется при открытии формы списка, проведении документа, формировании отчёта или при программном обращении к реквизиту. Журнал регистрации фиксирует событие с типом «Ошибка» и категорией «Платформа».

Причины появления

  • Прервано динамическое обновление конфигурации (выключение света, kill процесса).
  • Загрузка конфигурации (cf) поверх рабочей без реструктуризации.
  • Восстановление из бэкапа только файла данных (без метаданных) или наоборот.
  • Ручное вмешательство в SQL-таблицы (удаление полей через SSMS).
  • Сбой при реструктуризации больших таблиц по нехватке места или TempDB.
  • Смена релиза платформы с изменением правил формирования имён физических полей.
  • Расширения, добавляющие/изменяющие реквизиты, которые отвалились после обновления.

Способ 1: Реструктуризация таблиц информационной базы

Самое частое и эффективное решение. Работает и для файловых, и для серверных баз. Все пользователи должны выйти, обязательно сделайте бэкап.

  1. Запустите Конфигуратор от имени администратора, откройте проблемную базу.
  2. Меню: Администрирование → Тестирование и исправление.
  3. Снимите все галки, оставьте только: «Реструктуризация таблиц информационной базы».
  4. Режим: «Тестирование и исправление», «При наличии ошибок — Не изменять».
  5. Запустите. На больших базах — несколько часов.
  6. После окончания запустите Предприятие и проверьте проблемный объект.

Если реструктуризация ругается на нехватку места в логах SQL — переведите БД в режим Simple Recovery на время операции, увеличьте размер tempdb.

Способ 2: Полная реструктуризация через изменение метаданных

Если способ 1 не помог, заставьте платформу перестроить таблицы принудительно.

  1. Конфигуратор → откройте конфигурацию.
  2. Найдите проблемный объект (по тексту ошибки — например, справочник Контрагенты).
  3. Откройте свойства реквизита, который не находится, измените его свойство (например, длину строки +1 символ).
  4. Сохраните конфигурацию (F7), при запросе принять изменения структуры — согласитесь.
  5. Дождитесь окончания реструктуризации.
  6. Верните длину обратно, снова сохраните.

Этот приём заставляет платформу пересобрать физическую структуру таблицы, что часто устраняет рассинхронизацию.

Способ 3: Сравнение метаданных с физической структурой (для MS SQL)

Если предыдущие способы не помогли, сравните, что есть в БД и что должно быть. Откройте SSMS, выполните для проблемной таблицы:

USE [имя_базы_1С];
SELECT name, system_type_name
FROM sys.dm_exec_describe_first_result_set('SELECT * FROM _Reference45', NULL, 0);

Сравните результат с описанием реквизитов справочника в Конфигураторе. Если поле есть в метаданных, но отсутствует в SQL — это и есть причина. Сопоставление номеров полей и реквизитов:

SELECT * FROM Config WHERE FileName LIKE '%DBNames%';

Можно использовать утилиту от 1С или сторонние просмотрщики структуры (Tool_1CD для файловых баз).

Способ 4: Выгрузка и загрузка через dt

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

  1. В Конфигураторе: Администрирование → Выгрузить информационную базу. Сохраните .dt.
  2. Создайте новую пустую информационную базу того же типа (файловую или серверную).
  3. В новой базе: Администрирование → Загрузить информационную базу, укажите .dt.

При выгрузке-загрузке платформа пересоздаёт всю физическую структуру с нуля по метаданным. Минус — на больших базах (от 50 ГБ) процесс может занять сутки и больше, dt-файл получается значительного размера.

Способ 5: Восстановление из резервной копии

Если ничего из вышеперечисленного не помогло или структура повреждена настолько, что Конфигуратор не открывает базу, разворачивайте бэкап.

  1. Файловая база: скопируйте 1Cv8.1CD из последнего рабочего бэкапа.
  2. Серверная база MS SQL: RESTORE DATABASE из full + differential + log backup.
  3. После восстановления накатите обновление повторно — на этот раз без прерываний.
  4. Данные за период между бэкапом и сбоем вводите заново или импортируйте из выгрузок.

Профилактика

Делайте полный бэкап перед каждым обновлением конфигурации, особенно перед обновлением типовой (БП, ЗУП, ERP). Не запускайте динамическое обновление на больших базах — только остановочное в монопольном режиме. Контролируйте свободное место на диске и в tempdb до начала реструктуризации (нужно минимум удвоенное место от размера самой большой таблицы). Не убивайте процесс 1С во время обновления — даже если кажется, что висит. Регулярно (раз в квартал) запускайте полное тестирование ИБ с реструктуризацией.

FAQ

Чем отличаются «логические» и «физические» поля в 1С?

Логическое поле — реквизит, как он описан в Конфигураторе (например, «ИНН» у справочника Контрагенты). Физическое поле — соответствующий столбец SQL-таблицы (например, _Reference45_Fld98). Платформа автоматически сопоставляет их по словарю DBNames.

Можно ли удалить поле напрямую в SQL Server Management Studio?

Категорически нельзя. Это гарантированно приведёт к ошибке SDBL и невозможности работы с базой. Все изменения структуры — только через Конфигуратор и реструктуризацию.

Реструктуризация идёт несколько часов — нормально?

Для больших баз (от 100 ГБ) это нормально. Платформа пересоздаёт таблицу, копирует данные, удаляет старую — длительность зависит от размера и количества индексов. Не прерывайте процесс.

Что делать, если Конфигуратор не открывает базу из-за этой ошибки?

Запустите Конфигуратор с параметром /F<путь_к_базе> /N<логин> /P<пароль> /DisableStartupMessages. Если не помогает — восстанавливайтесь из бэкапа.

Помогает ли утилита chdbfl.exe?

Для файловой базы — может помочь, если повреждены индексы. Для расхождения метаданных и структуры — нет, нужна реструктуризация через Конфигуратор. Запускайте: C:\Program Files\1cv8\8.3.x.xxxx\bin\chdbfl.exe с галкой «Исправлять».

Ошибка появилась после обновления типовой конфигурации. Откатить?

Сначала попробуйте реструктуризацию. Если не помогает — да, откатывайтесь на бэкап и обновляйтесь по правильному регламенту: монопольный режим, бэкап, обновление, тестирование, выпуск пользователей.

Можно ли работать в базе, если ошибка появляется только в одном отчёте?

Технически — да, но это симптом рассинхронизации, которая может проявиться в других местах. Лучше устранить причину сразу, в ближайшее окно обслуживания.

Алексей Герзанов aka Gerzoid
Алекс Гезанов

Работаю в сервисном центре по ремонту и обслуживанию бытовой техники. За более чем 10 лет трудовой деятельности, я сталкивался с решением большого количества проблем в работе ОС Windows, периферийных устройств, бытовой техники, игровых консолей Playstation и т. д.

Добавить комментарий