Как исправить ошибку SDBL: Тип поля CAST AS REF(DataHistoryLatestVersions) при переходе с Бухгалтерии 2.0 на 3.0

← На главную

Обновление конфигурации «1С:Бухгалтерия предприятия» с редакции 2.0 на 3.0 — это один из самых трудоемких процессов в сопровождении систем 1С. Переход подразумевает не просто смену интерфейса, но и радикальное изменение структуры базы данных, включая появление новых системных механизмов. Одной из наиболее неприятных преград на этом пути является ошибка SDBL (Simple Data Barrier Language), связанная с механизмом DataHistoryLatestVersions. Рассмотрим подробно, почему она возникает и как её устранить.

Выясним причину возникновения ошибки

Ошибка вида CAST(13106:00000000000000000000000000000000 AS REF(DataHistoryLatestVersions)) несовместим с типом поля FldXXXXX напрямую указывает на конфликт в механизме «История данных» (Data History). Этот функционал был массово внедрен в платформу, начиная с версии 8.3.11. Когда мы инициируем масштабную реструктуризацию (переход с 2.0 на 3.0), платформа пытается сопоставить старые данные с новыми системными таблицами версионирования.

Проблема заключается в том, что в процессе реструктуризации создаются временные таблицы. Платформа пытается привести пустую ссылку или идентификатор объекта к типу ссылки системной таблицы DataHistoryLatestVersions, но из-за различий в описании метаданных или накопленных «битых» ссылок в исходной базе происходит сбой логики формирования SQL-запроса.

Проанализируем ситуацию с конкретными полями СУБД

Часто программисты пытаются найти поле, указанное в ошибке (например, Fld34860), напрямую в SQL-таблицах базы данных. Однако стандартный запрос к системному представлению information_schema.columns может ничего не дать. Это происходит потому, что ошибка возникает во время работы с временными таблицами (с префиксами v8_ или tt), которые платформа создает и удаляет «на лету» в одной транзакции.

Разберем, как поймать «невидимку». Для этого нам потребуется настроить Технологический журнал (ТЖ) с акцентом на события SDBL и DBMSSQL. Пример настройки logcfg.xml для локализации проблемы:


<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
  <log location="C:\Logs\SDBL_Error" history="24">
    <event>
      <eq property="Name" value="SDBL"/>
    </event>
    <event>
      <eq property="Name" value="DBMSSQL"/>
    </event>
    <property name="all"/>
  </log>
</config>

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

Решение 1: Очистка истории данных перед обновлением

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


Процедура ОчиститьИсториюПередОбновлением()
    ИсторияДанных.ОчиститьВсе();
КонецПроцедуры

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

Решение 2: Исправление ошибок NULL в обязательных полях

Иногда ошибка SDBL является лишь следствием другой проблемы — наличия NULL в полях, которые в новой конфигурации (3.0) помечены как NOT NULL на уровне СУБД. Проанализируем пример сообщения: Cannot insert the value NULL into column '_Fld13492RRef', table 'dbo._Reference32'. Это означает, что в справочнике есть битые записи.

Посмотрим на алгоритм исправления:

Выясним имя справочника. В консоли 1С выполним:


Структура = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого Таблица Из Структура Цикл
    Если Таблица.ИмяТаблицыХранения = "_Reference32" Тогда
        Сообщить(Таблица.Имя);
    КонецЕсли;
КонецЦикла;

Найдем записи с NULL-значениями в SQL Management Studio: SELECT * FROM _Reference32 WHERE _Fld13492RRef IS NULL
Заполним эти поля корректными значениями пустых ссылок или удалим битые записи непосредственно в СУБД (предварительно сделав бэкап!).

Решение 3: Переход через промежуточную версию

Попытка обновиться с 2.0.66.99 сразу на 3.0.75.109 — это прыжок через несколько лет разработки платформы и конфигурации. Несмотря на то что 1С заявляет поддержку таких переходов, внутренние механизмы DataHistory могут не справиться с объемом изменений в метаданных.

Рассмотрим стратегию поэтапного обновления:

Обновимся до первой стабильной версии ветки 3.0 (например, 3.0.43.х).
Выполним первый запуск в режиме «1С:Предприятие», чтобы отработали все обработчики обновления данных.
Запустим «Тестирование и исправление» с включенными галками проверки логической и ссылочной целостности.
Только после этого продолжим движение к версии 3.0.75.109.

Решение 4: Обновление платформы

Ошибка CAST AS REF часто была связана с недоработками самой платформы в версиях 8.3.15 и 8.3.16. В этих релизах оптимизатор SDBL-запросов некорректно интерпретировал системные типы при обращении к метаданным истории. Рекомендуется использовать платформу версии 8.3.18.х или выше для проведения реструктуризации. Более современные версии содержат исправления для подобных случаев «зацикливания» типов при преобразовании.

Резюме и рекомендации

Если вы столкнулись с ошибкой несовместимости типов в DataHistoryLatestVersions, не паникуйте. Сначала проверьте целостность данных через ТиИ, затем попробуйте очистить историю данных программно. Если это не помогло, используйте Технологический журнал для поиска конкретной таблицы в SQL и проверьте её на наличие NULL в индексированных полях. Помните, что при переходе между редакциями последовательность действий важнее скорости.