Как исправить ошибку SDBL (Enum544) и дубликаты в уникальном индексе при обновлении УТ 11.3 на 11.4

При выполнении крупных обновлений в системе «1С:Предприятие», особенно при переходе между ключевыми редакциями (такими как переход с «Управление торговлей» версии 11.3 на 11.4), специалисты часто сталкиваются со сложными системными сбоями СУБД и механизма реструктуризации платформы. В этой статье мы подробно проанализируем две взаимосвязанные критические ошибки, которые делают процесс обновления невозможным, выясним их истинные причины и разберем по шагам надежные методы их устранения.

Часть 1. Ошибка SDBL: Ссылка на таблицу Enum544 недопустима (отсутствует RefSelf)

Рассмотрим природу первой проблемы. При запуске обновления конфигурации процесс аварийно завершается с сообщением: "Ошибка SDBL: Ссылка на таблицу Enum544 недопустима. Нет таблицы или отсутствует RefSelf".

Аббревиатура SDBL расшифровывается как Simple Data Base Layer — это собственный внутренний слой абстракции платформы «1С:Предприятие» для работы с базами данных. Он транслирует запросы 1С в диалект конкретной СУБД (MS SQL Server, PostgreSQL и др.). Ошибка сигнализирует о том, что во внутренних метаданных платформы нарушена логическая целостность.

В процессе перехода с УТ 11.3 на 11.4 разработчики компании «1С» приняли решение полностью исключить из состава метаданных перечисление УдалитьТипыОперацийЗаказаНаСборку (которое на уровне СУБД сопоставлено с таблицей Enum544). Однако из-за рассинхронизации между конфигурацией базы данных, основной конфигурацией и кэшем платформы, СУБД пытается обратиться к этой таблице в процессе реструктуризации, когда физически ее уже не должно существовать.

Попытка просто удалить физическую таблицу _Enum544 через среду SQL Server Management Studio (SSMS) не приносит результата. Платформа 1С хранит описание структуры базы данных в служебных таблицах Config и DBSchema. Если физическую таблицу удалить, а логическая запись о ней останется в метаданных, система выдаст еще более критическую ошибку.

Давайте разберем три рабочих способа решения этой проблемы.

Метод 1. Снятие признака поддержки для проблемного объекта (быстрый практический путь)

Этот способ позволяет быстро обойти ошибку SDBL непосредственно в Конфигураторе, если база данных находится на стандартной поддержке.

1. Откройте информационную базу в режиме Конфигуратор.
2. Перейдите в меню Конфигурация — Поддержка — Настройка поддержки.
3. В открывшемся окне нажмите кнопку Включить возможность изменения. При возникновении запросов системы согласитесь с сохранением правил поддержки (выберите вариант «Объект поставщика редактируется с сохранением поддержки»).
4. В дереве конфигурации найдите перечисление УдалитьТипыОперацийЗаказаНаСборку.
5. Нажмите на него правой кнопкой мыши, выберите пункт Установить правила поддержки и переведите его в статус Снят с поддержки.
6. После этого удалите данное перечисление из дерева конфигурации вручную.
7. Запустите обновление базы данных (клавиша F7). Платформа корректно удалит связанные ссылки, и ошибка SDBL исчезнет.

Метод 2. Синхронизация UUID метаданных через выгрузку в XML (для баз на строгой поддержке)

Если вы хотите сохранить конфигурацию на полностью закрытой поддержке без ручного редактирования объектов, мы можем выровнять идентификаторы (UUID) метаданных, из-за различия которых платформа теряет связь с объектом.

1. Выгрузите конфигурацию базы данных в файлы XML. Для этого выберите в меню: Конфигурация — Выгрузить конфигурацию в файлы... и укажите пустой каталог (например, C:\DB_XML).
2. Выгрузите основную конфигурацию (новую, подготовленную к обновлению) во второй каталог (например, C:\Main_XML).
3. Используйте утилиту сравнения текстовых файлов или встроенные средства сравнения XML. Проанализируйте служебный файл ConfigDumpInfo.xml из обоих каталогов.
4. Найдите узел, описывающий перечисление Enum544 (УдалитьТипыОперацийЗаказаНаСборку). Вы увидите, что его уникальный идентификатор (UUID) в конфигурации базы данных отличается от идентификатора в новой конфигурации (или вовсе отсутствует).
5. Замените UUID объекта в XML-файлах основной конфигурации на тот, который ожидает увидеть конфигурация базы данных.
6. Загрузите измененную конфигурацию обратно через пункт меню Конфигурация — Загрузить конфигурацию из файлов... и выполните обновление структуры базы данных.

Метод 3. Обход через создание узла РИБ

Данный недокументированный метод основан на том, что при создании начального образа распределенной информационной базы (РИБ) платформа 1С полностью пересобирает таблицы метаданных «с нуля», очищая накопившийся «мусор» и устаревшие кэшированные связи СУБД.

1. В исходной базе создайте новый узел в любом простом плане обмена (например, «Полный»).
2. Выполните создание начального образа для этого подчиненного узла на СУБД SQL Server.
3. Запустите полученную базу подчиненного узла в режиме Конфигуратора.
4. Отвяжите базу от главного узла, выполнив в простейшей обработке команду: ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
5. Запустите процедуру обновления на этой «очищенной» копии. Ошибка SDBL в большинстве случаев не воспроизводится. После успешного обновления базу можно перенести на рабочий сервер вместо исходной.

---

Часть 2. Ошибка реструктуризации: Не удается вставить повторяющуюся строку ключа в "_InfoRgSL25517NG"

Перейдем ко второй ошибке, которая часто возникает следом за первой при попытке выполнить реструктуризацию базы данных. Текст ошибки выглядит следующим образом:

"Microsoft SQL Server Native Client 11.0: Не удается вставить повторяющуюся строку ключа в объект 'dbo._InfoRgSL25517NG' с уникальным индексом '_InfoRgS25517_ByDimsNG'. Повторяющееся значение ключа: (0, 0x9714d43d7eebab141e..., ...)"

Проанализируем структуру и поймем, почему стандартный SQL-запрос автора темы на поиск дубликатов не дал результатов.

Таблица _InfoRgSL25517 на физическом уровне представляет собой вспомогательную таблицу виртуальной таблицы «Срез последних» для регистра сведений ЦеныНоменклатурыПоставщиков. Буквы SL в названии таблицы как раз указывают на Slice Last (Срез последних). Платформа 1С оптимизирует запросы среза последних, сохраняя актуальные данные в эту отдельную таблицу СУБД, чтобы при каждом запросе не рассчитывать срез по основной таблице движений (_InfoRg25517).

Уникальный индекс _ByDimsNG расшифровывается как By Dimensions (По измерениям). Он гарантирует, что для каждого уникального набора измерений регистра в таблице среза последних может существовать только одна запись. В измерения регистра входят: Поставщик, Номенклатура, Вид цены и т.д.

Почему же запрос автора, приведенный ниже, показал отсутствие дубликатов?

SELECT count(*),_Period,_RecorderTRef,_RecorderRRef,_Fld19635RRef,_Fld11476RRef...
FROM [dbo].[_InfoRgSL25517]
GROUP BY _Period,_RecorderTRef,_RecorderRRef,_Fld19635RRef,_Fld11476RRef...
HAVING count(*) > 1

В этом запросе допущена методологическая ошибка: автор включил в группировку (GROUP BY) поля _Period (Период), _RecorderTRef / _RecorderRRef (Регистратор) и ресурсы регистра (например, цены). Но индекс _ByDimsNG строится исключительно по измерениям! Если в таблице среза последних по какой-то причине (например, сбой транзакции СУБД в прошлом) оказались две строки с абсолютно одинаковыми измерениями, но разными периодами или ценами:

• Для СУБД это дубликаты, так как индекс по измерениям вешается только на колонки измерений.
• Для группировки автора это разные строки (так как периоды или цены в них отличаются), поэтому функция COUNT(*) вернула единицу для каждой строки, скрыв проблему.

Рассмотрим два надежных метода исправления этой проблемы.

Метод 1. Поиск дубликатов с помощью корректного SQL-запроса

Чтобы локализовать реальные дубликаты, мы должны составить запрос, группирующий данные строго по полям измерений регистра. Для регистра ЦеныНоменклатурыПоставщиков это будут поля измерений (исключая служебные поля периода, регистратора и ресурсов):

SELECT 
    COUNT(*) as DoublesCount, 
    _Fld19635RRef, -- Измерение 1 (например, Партнер)
    _Fld11476RRef, -- Измерение 2 (например, Номенклатура)
    _Fld11477RRef, -- Измерение 3 (например, Характеристика)
    _Fld11478RRef  -- Измерение 4 (например, Соглашение)
FROM 
    [dbo].[_InfoRgSL25517]
GROUP BY 
    _Fld19635RRef, 
    _Fld11476RRef, 
    _Fld11477RRef, 
    _Fld11478RRef
HAVING 
    COUNT(*) > 1;

Запустив этот запрос в SSMS, мы получим список конкретных записей-дублей. После этого одну из дублирующихся строк с одинаковым набором измерений необходимо удалить вручную из базы данных SQL, оставив только актуальную строку с наиболее поздним периодом.

Метод 2. Полная очистка таблицы среза последних (рекомендуемый и самый быстрый способ)

Поскольку таблица _InfoRgSL25517 является всего лишь кэшем виртуальной таблицы, нам нет необходимости тратить время на ручной поиск и удаление сотен дубликатов. Все основные данные движений физически и надежно сохранены в главной таблице регистра — _InfoRg25517.

Мы можем применить безопасный алгоритм полной регенерации кэша среза последних:

1. Откройте SQL Server Management Studio, подключитесь к вашей базе данных и выполните команду полной очистки (транкации) вспомогательной таблицы среза последних: TRUNCATE TABLE dbo._InfoRgSL25517; Важно: Убедитесь, что вы очищаете именно таблицу с буквами SL в названии. Основную таблицу регистра движений (без SL) трогать ни в коем случае нельзя!
2. После успешного выполнения команды вернитесь в Конфигуратор 1С и запустите процесс обновления конфигурации (клавиша F7) или реструктуризацию в режиме Тестирования и исправления. Процесс пройдет мгновенно и без ошибок, так как пустая таблица не содержит конфликтующих индексов.
3. Как только обновление конфигурации будет успешно завершено, запустите базу в режиме Конфигуратора.
4. Перейдите в меню Администрирование — Тестирование и исправление....
5. Установите флаг напротив пункта Реиндексация таблиц информационной базы и обязательно отметьте пункт Пересчет итогов.
6. Нажмите кнопку Выполнить.

В ходе пересчета итогов платформа «1С:Предприятие» обратится к основной таблице движений регистра сведений, автоматически выберет самые актуальные записи по каждой номенклатуре и поставщику, и заново запишет их в таблицу _InfoRgSL25517. При этом все новые записи будут гарантированно уникальными, а структура индексов СУБД останется абсолютно целостной.

Заключение

Мы детально разобрали внутренние механизмы СУБД при обновлении конфигураций «1С». Понимание устройства физических таблиц (таких как таблицы среза последних _InfoRgSL) позволяет администраторам баз данных оперативно решать технические проблемы обновления, не прибегая к радикальной потере важных исторических данных.