При выполнении стандартной операции поиска и замены дублирующих элементов в базах данных «1С:Предприятие» пользователи и администраторы иногда сталкиваются с неожиданным и пугающим сбоем. Система прерывает работу, выдавая системное сообщение: «Ошибка SDBL: Поле отличается по принадлежности к вложенным таблицам от поля в предыдущем варианте». Данная ошибка происходит на уровне СУБД и транслятора запросов, делая невозможным полуавтоматическое слияние элементов.
В этой статье мы подробно разберем природу этого сбоя, выясним причины его возникновения, проанализируем внутреннее устройство механизмов платформы 1С и рассмотрим пошаговые методы устранения данной проблемы.
Для начала разберем структуру сообщения об ошибке. Аббревиатура SDBL (Simple Data Base Layer) означает внутренний слой платформы 1С, который выступает посредником между объектной моделью встроенного языка и физической базой данных (MS SQL Server, PostgreSQL, IBM DB2 или Oracle). SDBL переводит запросы «1С» во внутренний SQL-код.
Когда вы видите системные имена вида Document6014.VT6018.Fld6023, платформа обращается к физическим таблицам СУБД. Расшифруем эту запись:
РеализацияТоваровУслуг или ПоступлениеТоваровУслуг).Товары).Номенклатура или ДоговорКонтрагента).Услуги или Спецификации).23:afe8000423ba5cb811dba13a658e9c3a — это уникальные идентификаторы (GUID) элементов справочника, которые вы пытаетесь заменить. Число 23 указывает на внутренний код типа объекта метаданных.Суть конфликта заключается в том, что при замене дублей платформа запускает глобальный поиск ссылок по всей базе данных с помощью метода НайтиПоСсылкам. SDBL пытается оптимизировать SQL-запрос, объединяя выборки из разных табличных частей одного документа. Из-за внутренней ошибки оптимизатора запросов система некорректно сопоставляет контексты вложенных таблиц и аварийно завершает транзакцию.
Данная проблема представляет собой критический платформенный баг. Он был массово зафиксирован в релизах ветки платформы 8.3.14 (наиболее выражен в сборке 8.3.14.1630). Ошибка воспроизводится только тогда, когда заменяемый элемент одновременно используется в нескольких различных табличных частях (ТЧ) одного и того же документа. Если элемент встречается только в одной ТЧ или только в шапке документа, слияние проходит штатно.
Рассмотрим подробнее три основных метода решения этой проблемы.
Поскольку ошибка локализована непосредственно в трансляторе запросов SDBL, исправить её кодом конфигурации на проблемных релизах невозможно. Фирма «1С» оперативно выпустила исправление этого бага.
Проанализируем шаги для устранения проблемы через обновление:
8.3.14.1565 – 8.3.14.1630, вы гарантированно подвержены этому багу.Если по каким-то причинам вы не можете обновить платформу прямо сейчас (например, требуется длительное согласование с ИТ-отделом или база находится на строгом обслуживании), можно обойти ошибку вручную. Для этого нам нужно понять, в каких именно документах заменяемые элементы пересекаются в разных табличных частях.
Разберем этот процесс по шагам:
Шаг 1. Дешифровка имен таблиц СУБД. Нам необходимо сопоставить системные имена таблиц из ошибки с реальными объектами метаданных конфигурации. Для этого запустим обработку со следующим кодом:
ТаблицаСтруктуры = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого СтрокаСтруктуры Из ТаблицаСтруктуры Цикл
Если СтрокаСтруктуры.ИмяТаблицыХранения = "Document6014" Тогда
Сообщить("Имя документа в конфигураторе: " + СтрокаСтруктуры.ИмяТаблицы);
Для Каждого Поле Из СтрокаСтруктуры.Поля Цикл
Если Поле.ИмяПоляХранения = "Fld6023" Тогда
Сообщить("Имя реквизита в ТЧ: " + Поле.ИмяПоля);
КонецЕсли;
КонецЦикла;
КонецЕсли;
КонецЦикла;
Этот код выведет в окно сообщений настоящее имя документа и реквизитов. Предположим, мы выяснили, что документ — это РеализацияТоваровУслуг, первая ТЧ — Товары, а вторая — Услуги.
Шаг 2. Поиск проблемных документов. Теперь напишем запрос, чтобы найти конкретные документы, в которых одновременно выбраны заменяемые дубликаты. Нам известны GUID элементов из ошибки (например, afe80004-23ba-5cb8-11db-a13a658e9c3a). Нам нужно найти ссылки на эти элементы в базе данных:
// Создадим запрос для поиска документов, содержащих дубли в разных ТЧ
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ РАЗЛИЧНЫЕ
| РеализацияТоваров.Ссылка КАК ДокументСсылка
|ИЗ
| Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваров
|ГДЕ
| РеализацияТоваров.Номенклатура В (&СписокДублей)
|
|ИНТЕРСЕКТ (ВЫБРАТЬ
| РеализацияУслуг.Ссылка
|ИЗ
| Документ.РеализацияТоваровУслуг.Услуги КАК РеализацияУслуг
|ГДЕ
| РеализацияУслуг.Номенклатура В (&СписокДублей))";
СписокЭлементов = Новый Массив;
СписокЭлементов.Добавить(Справочники.Номенклатура.ПолучитьСсылку(Новый УникальныйИдентификатор("afe80004-23ba-5cb8-11db-a13a658e9c3a")));
СписокЭлементов.Добавить(Справочники.Номенклатура.ПолучитьСсылку(Новый УникальныйИдентификатор("b833f46d-04e2-3350-11e8-f2135894286b")));
Запрос.УстановитьПараметр("СписокДублей", СписокЭлементов);
РезультатЗапроса = Запрос.Выполнить();
Шаг 3. Временное устранение пересечений. После того как вы получите список конкретных проблемных документов, откройте их и временно удалите дублирующийся элемент из одной из табличных частей (или замените его вручную на правильный). Как только пересечение в рамках одного документа будет устранено, обработка «Поиск и замена дублей» отработает без ошибок SDBL.
Иногда ошибки SDBL могут возникать из-за рассинхронизации кэша метаданных платформы и СУБД. Если вы обновили платформу, но ошибка продолжает периодически возникать на некоторых рабочих станциях, выполните комплекс профилактических процедур:
ragent (Агент сервера 1С:Предприятия), перейдите в каталог кластера (по умолчанию это C:\Program Files\1cv8\srvinfo) и удалите папки с временными файлами кэша сеансов. После этого запустите службу заново./ClearCache или удалите базу из списка запуска и добавьте её повторно (это очистит локальные настройки метаданных на компьютере пользователя).Применяя данные методы, мы гарантированно избавимся от ошибки SDBL и сможем продолжить успешное обслуживание и актуализацию данных в информационной базе «1С:Предприятие».