← На главную

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

Ошибка SDBL: Ссылка на таблицу Enum... недопустима. Нет таблицы или отсутствует RefSelf.

Чаще всего в тексте ошибки упоминаются таблицы Enum475 или Enum304, которые в системной структуре базы данных соответствуют метаданным перечисления Перечисление.УдалитьТипыОперацийЗаказаНаСборку. Давайте подробно разберем, почему возникает этот программный сбой, и проанализируем все доступные методы его решения — от стандартных штатных средств до глубокой ручной работы со структурами СУБД и XML-файлами конфигурации.

Выясняем техническую причину проблемы

Для начала разберем природу механизма SDBL (Simple Data Base Layer). Это внутренний слой платформы «1С:Предприятие», который служит абстракцией между объектной моделью метаданных 1С и реляционными таблицами СУБД (будь то MS SQL Server, PostgreSQL, IBM DB2 или Oracle). Когда мы запускаем обновление конфигурации базы данных, SDBL транслирует изменения метаданных в SQL-запросы для изменения физической структуры таблиц.

В процессе перехода с УТ 11.3 на 11.4 разработчики компании 1С удаляют устаревшие объекты метаданных, включая перечисление Перечисление.УдалитьТипыОперацийЗаказаНаСборку. В этот момент может произойти рассинхронизация:

1. В конфигурации базы данных (хранящейся в системных таблицах СУБД) и в основной конфигурации метаданные этого объекта начинают обладать несогласованными уникальными идентификаторами (UUID).
2. Платформа считает, что объект должен существовать в физической структуре данных для корректного удаления, но СУБД сообщает, что соответствующей таблицы (например, _Enum475) в базе данных нет, либо нарушены внутренние ссылки самоидентификации таблицы (RefSelf).
3. Процесс обновления аварийно прерывается, оставляя базу данных в промежуточном («битом») состоянии. При попытке повторного входа или обновления мы снова получаем ту же ошибку SDBL.

Ниже мы подробно рассмотрим по шагам, как преодолеть это препятствие и успешно завершить переход на новую редакцию программы.

Способ 1. Выборочная реструктуризация таблиц через Тестирование и исправление (Рекомендуемый)

Если база данных имеет умеренный объем, лучшим и самым безопасным решением будет запуск штатного механизма платформы. Однако классическое полное тестирование может занять слишком много времени. Нам необходимо выполнить процедуру точечно.

Рассмотрим пошагово этот алгоритм:

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

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

Способ 2. Очистка и принудительное обновление кэша конфигурации

Иногда корни проблемы лежат в локальном или серверном кэше платформы. На старый кэш метаданных накладывается новая структура, вызывая ложное срабатывание SDBL. Обычная очистка временных файлов пользователя помогает не всегда. Проанализируем более глубокий метод очистки:

1. Полностью закройте все сеансы работы с базой данных (включая консоль кластера серверов 1С, если база серверная).
2. Откройте список информационных баз в стартовом окне запуска 1С.
3. Выберите проблемную базу, нажмите кнопку «Изменить» и скопируйте ее путь или имя на сервере, после чего удалите базу из списка.
4. Создайте новую строку запуска для этой базы. Для надежности слегка измените ее наименование в списке (например, добавьте точку в конце названия). Это заставит платформу создать абсолютно новые каталоги кэша на жестком диске компьютера, полностью проигнорировав старые связки.
5. Если база серверная, выполните перезапуск службы «sh9_1C:Enterprise 8.3 Server Agent» (или аналогичной службы вашего сервера приложений) для принудительного сброса серверного кэша метаданных.

Способ 3. Ручное исправление UUID метаданных через XML (Для крупных баз)

Что делать, если база данных весит несколько сотен гигабайт, а тестирование и исправление с реструктуризацией выполняется несколько суток, что абсолютно неприемлемо для непрерывного бизнеса клиента? В этом случае мы можем прибегнуть к искусственному восстановлению соответствия идентификаторов без изменения самих физических таблиц.

Давайте разберем этот процесс по шагам:

1. Выгрузите конфигурацию, которая находится в процессе обновления (но еще не применена к базе данных), в файлы XML. Для этого в Конфигураторе выберите «Конфигурация» — «Выгрузить конфигурацию в файлы...» и укажите пустую директорию (назовем ее Папка 1).
2. Откройте с помощью текстового редактора (например, Notepad++) файл описания структуры метаданных ConfigDumpInfo.xml из Папки 1.
3. Найдите строку, содержащую описание проблемного объекта — перечисления УдалитьТипыОперацийЗаказаНаСборку. Зафиксируйте его имя и уникальный идентификатор (UUID).
4. Вернитесь к конфигурации базы данных (откатите изменения назад или запустите конфигурацию БД). Выгрузите конфигурацию базы данных в файлы в другую директорию (Папка 2).
5. Найдите аналогичный файл ConfigDumpInfo.xml в Папке 2, отыщите там наше перечисление и скопируйте его «родной» UUID из атрибута id тега <Metadata>.
6. Замените ошибочный идентификатор в файлах конфигурации Папки 1 на корректный UUID из Папки 2 (изменения нужно внести как в файл структуры ConfigDumpInfo.xml, так и в сам XML-файл описания этого перечисления в заголовке тега uuid="...").
7. В Конфигураторе выполните загрузку измененных файлов обратно через меню «Конфигурация» — «Загрузить конфигурацию из файлов...» (указав Папку 1) и нажмите F7 для обновления конфигурации базы данных.

Благодаря этому действию платформа сопоставит объект со старым физическим аналогом в СУБД по верному UUID и беспрепятственно удалит его из структуры данных.

Способ 4. Проверка и очистка таблиц регистрации изменений планов обмена

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

Рассмотрим, как решить эту проблему:

1. Перед обновлением запустите специализированную обработку «Регистрация изменений для обмена» (она входит в состав состава стандартной БСП и доступна в функциях для технического специалиста).
2. Проверьте, зарегистрированы ли изменения по объекту Перечисление.УдалитьТипыОперацийЗаказаНаСборку на каких-либо узлах планов обмена.
3. Если регистрация присутствует, полностью отмените ее для данного объекта по всем узлам.
4. В критических ситуациях на SQL-сервере можно аккуратно проверить наличие системных таблиц регистрации изменений (таких как _ConfigChngR или _ConfigChngR_ExtProps) и очистить записи, указывающие на идентификатор удаляемого перечисления.

Способ 5. Обход проблемы через создание временного РИБ-узла

Еще один нетривиальный, но эффективный способ обхода ошибки на больших базах без проведения долгого тестирования и исправления заключается в использовании механизма распределенных информационных баз (РИБ):

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

Способ 6. Влияние версии платформы «1С:Предприятие»

Иногда виновником ошибки SDBL выступает конкретный релиз платформы 1С. В версиях линеек 8.3.11, 8.3.12 и 8.3.13 присутствовали зафиксированные технологические ошибки реструктуризации баз данных при удалении объектов метаданных.

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

Используя приведенные методики, вы гарантированно сможете преодолеть ошибку SDBL при обновлении вашей конфигурации УТ 11.3 на 11.4 и успешно перевести информационную базу на новую ветку развития программного продукта.