При переходе со старых редакций конфигураций (например, с «Бухгалтерии для Украины» редакции 1.2 на 2.0 или аналогичных российских редакций) специалисты часто сталкиваются с критической ошибкой реструктуризации базы данных. Ошибка сопровождается сообщением: «Ошибка SDBL: Таблица или поле parentPredefinedID не содержится в разделе FROM». Эта проблема блокирует процесс обновления и не всегда устраняется стандартным тестированием и исправлением. В этой статье мы подробно разберем природу этой ошибки и пошагово пройдем путь ее локализации и устранения.
Для начала проанализируем ситуацию. Поле parentPredefinedID является системным полем платформы «1С:Предприятие 8.3». Оно используется для обеспечения связи между предопределенными элементами в иерархических справочниках. Ошибка возникает в тот момент, когда платформа пытается выполнить SQL-запрос для сопоставления родительских связей предопределенных данных, но в текущей структуре таблиц (в версии 1.2) это поле отсутствует или работает некорректно из-за различий в настройках иерархии между старой и новой конфигурациями.
Чаще всего это происходит со справочниками, которые в старой редакции были плоскими (без иерархии), а в новой редакции стали иерархическими. Рассмотрим, как найти конкретный объект, вызывающий сбой.
Если база данных большая, перебирать все справочники вручную невозможно. Для точного определения «виновника» нам потребуется настроить технологический журнал. Создадим в каталоге с установленной платформой (обычно это C:\Program Files\1cv8\conf) файл с именем log.cfg.
Пропишем в нем настройки для отслеживания исключительных ситуаций:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<dump create="true" location="C:\dumps" prntscrn="true" type="2"/>
<log history="72" location="C:\logs">
<event><eq property="name" value="EXCP"/></event>
<event><eq property="name" value="EXCPCNTX"/></event>
<event><eq property="name" value="PROC"/></event>
<event><eq property="name" value="ADMIN"/></event>
<event><eq property="name" value="MEM"/></event>
<event><eq property="name" value="LEAKS"/></event>
<property name="all"/>
</log>
</config>
После создания файла запустим процесс обновления конфигурации снова до появления ошибки. Затем откроем папку C:\logs и найдем свежий файл лога. Нас интересует строка с текстом EXCP, где зафиксирована ошибка SDBL. В логе мы увидим примерно следующее:
SELECT T1.PredefinedID PredefinedID, ... FROM #mdUpdated_O2 T1 INNER JOIN Reference127 T2 ON T1.parentPredefinedID = T2.PredefinedID
Обратим внимание на фрагмент INNER JOIN Reference127. Имя Reference127 — это внутреннее имя таблицы в базе данных SQL (или файловой БД). Теперь нам нужно понять, какому объекту метаданных оно соответствует.
Для того чтобы выяснить, какой справочник скрывается за именем Reference127, воспользуемся встроенной функцией платформы ПолучитьСтруктуруХраненияБазыДанных. Создадим внешнюю обработку и разместим в ней код, который выведет нам список соответствий:
Процедура КнопкаВыполнитьНажатие(Кнопка)
// ТЗНазвания - это таблица значений на форме с колонками "Справочник" и "Название"
ТЗНазвания.Очистить();
МассивИменМетаданных = Новый Массив();
Для каждого Объект Из Метаданные.Справочники Цикл
МассивИменМетаданных.Добавить(Объект.ПолноеИмя());
КонецЦикла;
// Получаем таблицу, содержащую структуру хранения для всех справочников
ТаблицыСтруктуры = ПолучитьСтруктуруХраненияБазыДанных(МассивИменМетаданных);
Для Каждого Таблица Из ТаблицыСтруктуры Цикл
НоваяСтрока = ТЗНазвания.Добавить();
НоваяСтрока.Справочник = Таблица.Метаданные;
НоваяСтрока.Название = Таблица.ИмяТаблицыХранения;
КонецЦикла;
КонецПроцедуры
Запустив эту обработку в исходной базе (до обновления), мы легко найдем, что Reference127 — это, к примеру, справочник СпособыОтраженияЗарплатыВРеглУчете.
Разберем ситуацию на примере найденного справочника СпособыОтраженияЗарплатыВРеглУчете. Проанализируем настройки:
Из-за того, что база данных содержит предопределенные элементы, платформа при реструктуризации пытается обработать их по правилам иерархического справочника, используя поле parentPredefinedID, которого физически еще нет в таблице.
Решение: В исходной базе (версии 1.2) необходимо зайти в конфигуратор, найти проблемный справочник и вручную установить галочку Иерархический. После этого нужно сохранить конфигурацию базы данных (нажать F7). Теперь платформа создаст необходимые системные поля. После этой процедуры обновление на версию 2.0 пройдет без ошибок.
Рассмотрим еще несколько важных моментов, которые могут помочь, если вышеописанный метод не является единственной проблемой:
Иногда ошибка SDBL вызвана тем, что в базе данных нарушена связь между именами предопределенных элементов в метаданных и записями в таблицах. Рекомендуется перед обновлением выполнить следующие действия:
Проанализируем техническую сторону: данная ошибка часто проявляется на определенных релизах платформы (например, ветки 8.3.14 или 8.3.15). Если ручное включение иерархии не помогает, попробуйте временно обновить платформу до более стабильной и высокой версии (например, 8.3.18 или 8.3.22) только на время выполнения обновления конфигурации. После успешной конвертации данных можно будет вернуться на целевую версию платформы.
Помимо способов отражения зарплаты, аналогичную проблему при переходе на новые редакции могут вызывать следующие справочники:
Во всех этих случаях механизм исправления один и тот же: синхронизация настроек иерархии в старой базе с настройками в новой конфигурации перед началом процесса обновления.
Таким образом, мы выяснили, что ошибка SDBL — это не приговор для базы данных, а следствие глубоких изменений в архитектуре метаданных. Использование технологического журнала и прямое управление свойствами объектов позволяют успешно преодолеть этот этап обновления.