В процессе обновления или приведения измененной конфигурации 1С к типовому виду разработчики часто сталкиваются с критическими сбоями механизма реструктуризации базы данных. Один из наиболее неприятных сбоев — ошибка уровня SDBL (System Database Layer):
В процессе обновления информационной базы произошла критическая ошибка. Таблица или поле Fld36505 не содержится в разделе FROM (pos=583)
Данная ошибка означает, что внутренний слой платформы 1С пытается обратиться к физической колонке таблицы СУБД (в нашем примере это Fld36505), которая по какой-то причине отсутствует в структуре базы данных или не совпадает с внутренним описанием метаданных платформы. Чаще всего это происходит при попытке «даунгрейда» конфигурации — удаления неиспользуемых доработок и возврата к стандартному программному продукту.
В этой статье мы подробно разберем природу возникновения этой ошибки и проанализируем наиболее эффективные методы ее устранения: от штатных проверок до прямого вмешательства в СУБД и альтернативного переноса данных.
При обновлении конфигурации платформа 1С выполняет реструктуризацию таблиц. Она создает временные таблицы, переносит туда данные, удаляет старые объекты, а затем переименовывает новые таблицы. Если в процессе этого алгоритма платформа сталкивается с рассогласованием (например, объект метаданных в конфигурации заявляет наличие реквизита, а физически в таблице СУБД его нет, либо наоборот), SDBL-транслятор запросов формирует некорректный SQL-запрос, вызывая аварийное завершение процесса.
Основные причины сбоя:
Рассмотрим по шагам методы решения этой проблемы.
---
Прежде чем что-то чинить, нам необходимо точно узнать, какому объекту метаданных (справочнику, документу, регистру) принадлежит загадочное поле Fld36505. Для этого мы настроим Технический журнал 1С.
Создадим текстовый файл с именем log.cfg в каталоге установки платформы (по умолчанию это C:\Program Files\1cv8\conf\ или C:\Program Files (x86)\1cv8\conf\). Вставим в него следующий код настройки:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\v8_logs" history="24">
<event>
<eq property="Name" value="EXCP"/>
</event>
<event>
<eq property="Name" value="EXCPCNTX"/>
</event>
<property name="all"/>
</log>
</config>
После этого запустим обновление в Конфигураторе и дождемся воспроизведения ошибки. Платформа запишет лог в папку C:\v8_logs. Откроем лог-файл и найдем поиском имя нашего поля. Мы увидим SQL-запрос, в котором фигурирует имя физической таблицы СУБД, например, _InfoRg18245 (Регистр сведений) или _Document340 (Документ).
Теперь, зная имя таблицы, откроем консоль запросов в режиме «Предприятие» и выполним следующий код, чтобы сопоставить физическую таблицу с объектом 1С:
СтруктураБД = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого СтрокаТаблицы Из СтруктураБД Цикл
Если СтрокаТаблицы.ИмяТаблицыХранения = "_InfoRg18245" Тогда
Сообщить("Это объект: " + СтрокаТаблицы.Метаданные);
КонецЕсли;
КонецЦикла;
Определив «проблемный» объект метаданных, мы сможем применить к нему точечные меры.
---
Если в процессе диагностики выяснилось, что поле принадлежит общему реквизиту, ни в коем случае не пытайтесь удалить его или заменить конфигурацию на типовую одним действием. Выполним процедуру поэтапно:
.cf) типового решения.---
Если база данных работает в клиент-серверном варианте (MS SQL Server, PostgreSQL), и штатные средства пасуют, мы можем «обмануть» платформу, добавив недостающее поле вручную на уровне СУБД.
Проанализируем ситуацию: СУБД-транслятор 1С ожидает увидеть поле _Fld36505 в таблице _InfoRg18245, но физически его там нет. Давайте создадим его.
Откроем среду управления СУБД (например, SQL Server Management Studio) и выполним запрос:
ALTER TABLE dbo._InfoRg18245 ADD _Fld36505 INT NULL;
Примечание: тип данных (INT, VARCHAR и т.д.) следует подбирать исходя из предполагаемого типа удаленного реквизита. Если точный тип неизвестен, числовой тип INT или пустая строка неограниченной длины обычно позволяют платформе пройти этап проверки.
После добавления поля вернемся в Конфигуратор и запустим обновление (F7). Платформа успешно обнаружит поле, завершит реструктуризацию без ошибок, а затем сама корректно удалит эту колонку, так как в новой конфигурации этот реквизит отсутствует. Это самый быстрый способ победить ошибку SDBL «в лоб».
---
Один из самых изящных и безопасных способов очистить базу данных от «мусорных» физических таблиц без ручного редактирования SQL — это использование Распределенных Информационных Баз (РИБ). При создании начального образа подчиненного узла РИБ платформа 1С генерирует физическую структуру базы данных «с нуля», перенося туда только актуальные и корректные данные, исключая все «хвосты» реструктуризации.
Выполним следующие шаги:
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
---
Если база данных сильно повреждена, а количество доработанных и неиспользуемых реквизитов исчисляется десятками, лучшим решением будет развернуть абсолютно чистую типовую базу нужного релиза и перенести в нее данные.
Для этого воспользуемся специализированной обработкой ВыгрузкаЗагрузкаДанныхXML.epf (ее можно найти на диске ИТС или в каталогах шаблонов конфигураций):
ВыгрузкаЗагрузкаДанныхXML включим опцию «Игнорировать несуществующие реквизиты и объекты метаданных» (или аналогичную опцию в зависимости от версии обработки).---
Иногда ошибка SDBL является следствием банального сбоя кэша конфигурации или логического разрушения файловой базы данных. Перед тем как приступать к сложным манипуляциям, обязательно выполним базовые регламентные процедуры:
bin установленной платформы, запустим chkdbfl.exe, выберем файл 1Cv8.1CD и запустим проверку с исправлением ошибок..dt, создадим пустую чистую базу и загрузим этот файл обратно. Данная операция полностью перестраивает индексы и внутренние таблицы базы.Проанализировав все вышеописанные методы, мы можем прийти к выводу, что наиболее надежным и быстрым способом исправления ошибки при переходе на типовую конфигурацию является либо прямая корректировка таблицы SQL (Метод 3), либо создание новой чистой базы с переносом данных через РИБ/XML (Методы 4 и 5). Выберите наиболее подходящий для вашей инфраструктуры способ и не забывайте делать резервные копии перед любыми операциями!