Что делать, если после динамического обновления в 1С пропал справочник и возникает ошибка SDBL?

Динамическое обновление (в среде разработчиков также известное как «демоническое») — удобный механизм быстрого внесения изменений в рабочую базу 1С без выгона пользователей. Однако при затягивании в динамическое обновление структурных изменений метаданных (новые реквизиты, справочники, изменение типов полей) часто происходит сбой синхронизации кешей и служебных таблиц. В результате объект остается виден в дереве метаданных Конфигуратора, но исчезает из пользовательского интерфейса, а тестирование и исправление завершается аварийно с ошибкой вида: SDBL тип поля undefined не совместим с типом поля Fld....

Рассмотрим подробно причины возникновения этой проблемы и способы ее устранения — от безопасных штатных методов до прямого восстановления служебных таблиц СУБД MS SQL Server.

Выясним причину сбоя

Проанализируем ситуацию, которая приводит к подобному поведению системы:

1. Рассогласование структуры метаданных и физической базы данных: Внутренний механизм платформы 1С (SDBL) пытается сопоставить физическую колонку таблицы SQL (например, Fld10423) с описанием метаданных. Если метаданные повреждены или рассинхронизированы, платформа не может определить тип поля и считает его undefined.
2. Повреждение служебных таблиц конфигурации: При динамическом обновлении информация о структуре базы записывается в таблицы Config, DBSchema и бинарные параметры (в частности, dbnames в таблице Params). При сбое динамического обновления связь между реальными SQL-таблицами и их описанием рушится.

Важное предупреждение: Перед выполнением любых операций с базами данных обязательно остановите службу сервера приложений 1С (1C:Enterprise 8.3 Server Agent) и сделайте полные резервные копии базы данных СУБД (дамп .bak)!

Способ 1. Восстановление системных таблиц конфигурации из исправного бэкапа (MS SQL)

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

Разберем по шагам алгоритм действий:

1. Разворачиваем из имеющегося бэкапа (сделанного до сбойного динамического обновления) исправную тестовую базу данных (в примере ниже — ut-test).
2. Полностью останавливаем службу сервера приложений 1С, чтобы очистить серверный кэш метаданных.
3. Открываем SQL Server Management Studio (SSMS) и запускаем скрипт переносa таблиц конфигурации из исправной базы ut-test в рабочую базу (в примере — crm):

USE [crm]
GO

-- Очистка и замена таблицы ConfigSave
DELETE FROM [dbo].[ConfigSave]
GO
INSERT INTO [dbo].[ConfigSave]
SELECT * FROM [ut-test].[dbo].[Config]
GO

-- Очистка и замена таблицы _YearOffset
DELETE FROM [dbo].[_YearOffset]
GO
INSERT INTO [dbo].[_YearOffset]
SELECT * FROM [ut-test].[dbo].[_YearOffset]
GO

-- Очистка и замена основной конфигурации Config
DELETE FROM [dbo].[Config]
GO
INSERT INTO [dbo].[Config]
SELECT * FROM [ut-test].[dbo].[Config]
GO

-- Очистка и замена схемы базы DBSchema
DELETE FROM [dbo].[DBSchema]
GO
INSERT INTO [dbo].[DBSchema]
SELECT * FROM [ut-test].[dbo].[DBSchema]
GO

-- Очистка и замена служебных файлов Files
DELETE FROM [dbo].[Files]
GO
INSERT INTO [dbo].[Files]
SELECT * FROM [ut-test].[dbo].[Files]
GO

-- Очистка и замена версий информационных баз IBVersion
DELETE FROM [dbo].[IBVersion]
GO
INSERT INTO [dbo].[IBVersion]
SELECT * FROM [ut-test].[dbo].[IBVersion]
GO

-- Очистка и замена параметров Params (содержит dbnames)
DELETE FROM [dbo].[Params]
GO
INSERT INTO [dbo].[Params]
SELECT * FROM [ut-test].[dbo].[Params]
GO

После выполнения скрипта запускаем службу сервера 1С, заходим в Конфигуратор и обновляем конфигурацию базы данных уже в обычном (не динамическом) режиме.

Способ 2. Принудительное перестроение DBSchema через изменение метаданных

Если лезть в СУБД нет возможности, но Конфигуратор открывается и дает вносить изменения, попробуем заставить платформу принудительно пересчитать карту соответствия типов DBSchema и dbnames.

1. Открываем рабочую базу в Конфигураторе.
2. Находим восстанавливаемый объект или создаем фиктивный реквизит с типом Строка в любом справочнике.
3. Выполняем **обычное** (монопольное) обновление конфигурации базы данных через клавишу F7 (применить изменения). В этот момент платформа запустит процедуру реструктуризации и заново сформирует записи служебных таблиц.
4. После успешного завершения операции удаляем фиктивный реквизит и повторно обновляем конфигурацию БД.

Способ 3. Обновление базы через командную строку

Иногда обойти зависший кэш динамического обновления помогает явный запуск Конфигуратора в монопольном режиме через командную строку с ключом запрета динамических изменений:

"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" DESIGNER /S "ServerName\BaseName" /N "Admin" /P "Password" /UpdateDBCfg -Dynamic-

Параметр -Dynamic- запрещает выполнение динамического обновления и заставляет платформу провести стандартное сопоставление метаданных.

Профилактика: как избежать «демонического» обновления

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

• Используйте динамическое обновление **только** при правках программного кода в модулях (модуль объекта, модуль формы, менеджер).
• Если вносились изменения в состав реквизитов, справочники, документы, типы данных или план видов характеристик — обновляйте базу строго в монопольном режиме с завершением сеансов всех пользователей.
• Очищайте локальный кэш платформы на клиентских ПК и серверный кэш при проявлении нестандартных ошибок после обновления.