← На главную

Разберем ситуацию, с которой часто сталкиваются при неудачном обновлении базы данных 1С. Допустим, произошло некорректное обновление, после которого таблицу config заменили файлом из бэкапа. На первый взгляд, база работает исправно, однако при попытке изменить конкретный объект метаданных (например, План видов характеристик) и добавить туда новый реквизит возникает ошибка SDBL.

При этом штатный метод ПолучитьСтруктуруИнформационнойБазы() возвращает наличие добавленных ранее реквизитов, и на уровне физических таблиц SQL они действительно существуют. Но в Конфигураторе мы их не видим. Проанализируем причину такого поведения и рассмотрим рабочие способы решения этой проблемы.

Причины возникновения ошибки рассинхронизации

Сбой возникает из-за рассинхронизации трех уровней хранения метаданных в платформе 1С:

1. Основная конфигурация, хранящаяся в таблице Config.
2. Внутренний словарь структуры базы данных 1С — это структура dbnames, отвечающая за связку метаданных и реальных имен в СУБД.
3. Физическая структура таблиц непосредственно на стороне сервера баз данных (MS SQL, PostgreSQL).

Если вы восстановили из резервной копии только таблицу Config, база данных на уровне СУБД и внутренний словарь платформы продолжают «помнить» о добавленных полях, а сама конфигурация в Конфигураторе — уже нет. В итоге при попытке модификации сломанного объекта возникает конфликт имен и генерируется ошибка SDBL.

Где физически находится файл dbnames?

При возникновении подобной проблемы многие пытаются найти отдельную таблицу с именем dbnames. Выясним, где она располагается. В базах клиент-серверного формата (на базе MS SQL или PostgreSQL) такой самостоятельной таблицы нет. Вся эта структура хранится внутри системной таблицы Params. Чтобы найти эти данные на уровне СУБД, необходимо выполнять запрос к таблице Params, отбирая записи, у которых колонка FileName имеет значение DBNames.

Способы решения проблемы

Рассмотрим несколько проверенных алгоритмов устранения ошибки SDBL. Критически важно: перед выполнением любых действий с базой данных обязательно сделайте полный бэкап средствами вашей СУБД!

1. Очистка таблицы динамического обновления

Очень часто проблему усугубляют зависшие остатки неудачного динамического обновления. Рекомендуется полностью очистить таблицу ConfigSave (в ней платформа временно хранит изменения до их применения к основной конфигурации). На стороне SQL выполним следующий запрос:

DELETE FROM ConfigSave

После удаления записей из этой таблицы обязательно перезапустите службу сервера 1С, а также очистите серверный и клиентский кэш.

2. Полная загрузка конфигурации из файла (.cf)

Вместо частичной подмены таблиц в SQL (когда заменяют только Config или DBSCHEMA), выполним принудительную перестройку всей структуры. Разберем по шагам:

1. Создайте абсолютно пустую информационную базу.
2. Загрузите в нее таблицу Config из вашего резервного бэкапа на уровне СУБД.
3. Откройте эту временную базу в Конфигураторе и выгрузите файл конфигурации (в формате .cf).
4. В сломанной (рабочей) базе выполните действие «Загрузить конфигурацию из файла». Внимание: используйте именно «Загрузить...», а не «Сравнить и объединить».

Этот процесс заставит платформу принудительно перестроить таблицы, обновить внутренние словари и корректно записать информацию во все три слоя хранения.

3. Штатное тестирование и исправление

Запустите в Конфигураторе режим «Тестирование и исправление информационной базы». Обязательно отметьте опции проверки логической и структурной целостности. В некоторых случаях платформа 1С способна самостоятельно выявить расхождения между метаданными и физическими таблицами и автоматически их скорректировать (удалить лишние колонки или пересоздать нужные структуры).

4. Ручная корректировка структуры СУБД (Крайняя мера)

Так как функция ПолучитьСтруктуруИнформационнойБазы() наглядно показывает физические имена таблиц и полей (они имеют вид _Fld1234), можно вмешаться напрямую через SQL-запросы. Чтобы Конфигуратор больше не спотыкался об их наличие при попытке добавить новые реквизиты, вручную удалим эти «призрачные» поля из соответствующей таблицы Плана видов характеристик:

ALTER TABLE ИмяВашейТаблицы DROP COLUMN _Fld1234

Замените имена таблиц и полей на те, которые выявили при анализе структуры.

5. Использование низкоуровневых утилит

Для безопасного просмотра и редактирования внутренних таблиц 1С (включая извлечение и упаковку бинарных файлов из Params) рекомендуется применять специализированные программы для прямого чтения формата файлов баз данных 1С (например, Tool_1CD). Они позволяют корректно экспортировать и импортировать файл dbnames без риска повредить формат бинарных данных, что нередко случается при прямых SQL-запросах, если неверно обработать поля с бинарной информацией.

Ограничения и риски

Обязательно учитывайте, что любые прямые манипуляции с системными таблицами 1С (такими как Config, Params, ConfigSave) или изменение физической структуры данных на стороне СУБД в обход платформы нарушают лицензионное соглашение и лишают вас официальной поддержки от вендора. Такие действия могут привести к полной неработоспособности базы. Прибегайте к прямому редактированию SQL-таблиц только в критических ситуациях, когда стандартные средства Конфигуратора бессильны, и имея гарантированно рабочую резервную копию.