При переходе с версии 1С:ERP 2.4 на 2.5.8 (и более поздние релизы ветки 2.5) системные администраторы и программисты часто сталкиваются с трудностями на этапе реструктуризации базы данных. Одной из наиболее запутанных ошибок является сообщение: «Ошибка SDBL: Внутренняя ошибка: сбой при генерации INSERT AS SELECT». Ситуация осложняется тем, что ошибка может возникать даже на полностью типовых конфигурациях, находящихся на поддержке, и при использовании актуальных версий платформы и СУБД (например, PostgreSQL 14 и платформа 8.3.21).
В этой статье мы подробно разберем, почему возникает этот сбой, как механизм реструктуризации взаимодействует с СУБД и какой неочевидный инструмент платформы помогает решить проблему за несколько кликов.
Для начала разберемся, что такое SDBL (Simple Data Base Layer). Это внутренний уровень платформы «1С:Предприятие», который служит «переводчиком» между объектной логикой 1С и SQL-запросами конкретной СУБД. Когда мы запускаем обновление конфигурации, платформа анализирует изменения в метаданных. Если структура регистра или таблицы изменилась, 1С создает временную таблицу, переносит туда данные и заменяет старую таблицу новой.
Текст ошибки INSERT AS SELECT часто сбивает с толку пользователей PostgreSQL, так как это синтаксис, характерный для MS SQL Server. В PostgreSQL аналогичная команда выглядит как INSERT INTO ... SELECT. Однако важно понимать: ошибка возникает внутри платформы еще до того, как запрос отправляется в СУБД. Генератор SDBL пытается сопоставить поля старой и новой структуры, но натыкается на логическое несоответствие, которое не может обработать. Именно поэтому в логах самой СУБД (PostgreSQL) мы часто не видим никаких ошибочных запросов — выполнение прерывается на стороне толстого клиента или сервера 1С.
В процессе перехода с ERP 2.4 на 2.5 меняется логика многих регистров накопления. В ERP активно используются агрегаты — специальные таблицы, хранящие предварительно рассчитанные итоги для ускорения отчетов. Проблема заключается в том, что в базе данных могут остаться таблицы агрегатов от старой версии, которые платформа в новой версии уже «не видит» в дереве метаданных, но физически пытается обработать при реструктуризации основного регистра.
Рассмотрим ситуацию: в конфигураторе на вкладке «Агрегаты» у регистра накопления ничего не задано, а в пользовательском интерфейсе (через подсистему БСП «Обслуживание») кнопка очистки агрегатов неактивна. Однако в СУБД физически присутствуют таблицы с префиксами _AccumRegAgg... и _AccumRegAggDict.... Именно на попытке перестроить эти «сиротские» таблицы спотыкается механизм SDBL.
Одной из ключевых находок при решении этой проблемы является разграничение инструментов управления базой данных. В типичной конфигурации ERP есть две визуально похожих, но функционально разных обработки:
Если вы столкнулись со сбоем при генерации INSERT AS SELECT, выполните следующие действия:
Запустите базу в пользовательском режиме. Перейдите в «Настройки — Параметры» и установите флаг «Режим технического специалиста». После этого в главном меню станет доступен пункт «Функции для технического специалиста» (в старых версиях — «Все функции»).
В открывшемся окне разверните узел «Стандартные» и найдите обработку «Управление итогами». Важно использовать именно её, а не аналоги из меню администрирования.
В открывшейся обработке перейдите на вкладку «Агрегаты». Вы увидите список всех регистров, для которых в СУБД созданы таблицы итогов. Проанализируем список: если вы видите регистры, где использование агрегатов отключено (флажок снят), но при этом в колонках указано наличие данных — это и есть причина ошибки. Нажмите кнопку «Очистить агрегаты». Это действие удалит физические таблицы агрегатов из PostgreSQL, не затрагивая основные данные регистров.
Вернитесь в конфигуратор и запустите обновление конфигурации базы данных (клавиша F7). После удаления лишних таблиц генератор SDBL сможет корректно сформировать запросы на перенос данных, и процесс обновления ERP 2.5 завершится успешно.
Иногда очистки агрегатов бывает недостаточно, если база имеет долгую историю обновлений. Проанализируем дополнительные методы исправления:
.dt и загрузку в новую чистую базу. При загрузке 1С пересоздает структуру таблиц «с нуля» в соответствии с текущими метаданными, что часто устраняет фантомные объекты в СУБД.
Структура = ПолучитьСтруктуруХраненияБазыДанных(, Истина);
Для Каждого СтрокаТаблицы Из Структура Цикл
Если Найти(СтрокаТаблицы.ИмяТаблицыХранения, "accumregagg") > 0 Тогда
Сообщить("Найдена таблица агрегата: " + СтрокаТаблицы.ИмяТаблицы);
КонецЕсли;
КонецЦикла;
Этот код поможет выявить проблемные регистры накопления, которые требуют особого внимания при очистке итогов.
Ошибка SDBL при обновлении на ERP 2.5 чаще всего является следствием накопленных несоответствий в служебных таблицах СУБД. Использование встроенных инструментов платформы для очистки агрегатов через «Режим технического специалиста» — это наиболее быстрый и безопасный способ восстановить работоспособность процесса обновления, не прибегая к ручному удалению таблиц в PostgreSQL, которое может нарушить целостность базы данных.