При работе с внешними источниками данных (ВИД) в системе «1С:Предприятие» разработчики часто сталкиваются с ситуацией, когда таблица MS SQL Server использует тип uniqueidentifier (GUID) в качестве первичного ключа. Казалось бы, 1С поддерживает тип УникальныйИдентификатор, и проблем быть не должно. Однако на практике платформа может выдавать критическую ошибку SDBL, сообщая о несовместимости типов или пытаясь преобразовать GUID в Numeric(19,0). В этой статье мы подробно разберем причины такого поведения и рассмотрим несколько эффективных способов решения проблемы.
Проанализируем ситуацию: при попытке записи изменений или простом обращении к таблице внешнего источника 1С генерирует SQL-запрос, в котором фигурирует конструкция вида CAST(Field AS NUMERIC(19, 0)). Это происходит не потому, что 1С «не умеет» работать с GUID, а по ряду специфических внутренних причин:
Service Data Base Layer (SDBL) предъявляет строгие требования к ключевым полям. Если драйвер ODBC передает метаданные поля uniqueidentifier некорректно, 1С может интерпретировать его как двоичные данные или строку, что мешает его использованию в качестве типизированной ссылки.Как показывает практика, часто проблема решается простым «сбросом» настроек в конфигураторе. Рассмотрим этот алгоритм по шагам:
Во-первых, если поле внешнего источника уже используется в качестве типа реквизита в каком-либо справочнике или документе, необходимо временно очистить этот тип. Установите тип реквизита в ЛюбаяСсылка или просто удалите связь с внешним источником.
Во-вторых, удалите таблицу из состава Внешнего источника данных в дереве метаданных. После удаления обязательно выполните сохранение конфигурации и обновление конфигурации базы данных (F7). Это критически важно для того, чтобы SDBL очистил свои внутренние таблицы описания типов (такие как Config и DBSchema).
В-третьих, заново добавьте таблицу во внешний источник, выберите поле ID и явно укажите тип УникальныйИдентификатор. Снова обновите конфигурацию базы данных. Теперь, когда «чистые» метаданные прописаны, можно вернуть тип реквизита в справочнике на обновленную таблицу внешнего источника.
Если стандартный маппинг GUID в УникальныйИдентификатор продолжает выдавать ошибки, мы можем применить обходной путь, представив идентификатор в виде строки. Это наиболее стабильный вариант, если вам не требуется выполнять сложные математические операции с ключом на стороне SQL.
Рассмотрим, как это реализовать:
uniqueidentifier в nvarchar(36):
CREATE VIEW v_ExternalData AS
SELECT
CAST(ID AS NVARCHAR(36)) AS ID_String,
Name,
OtherFields
FROM OriginalTable
В 1С при импорте этого представления выберите поле ID_String в качестве ключевого и установите ему тип Строка. Платформа перестанет воспринимать это поле как объектный идентификатор, требующий специальной обработки SDBL, и будет работать с ним как с обычным текстовым кодом. Это гарантированно убирает ошибку CAST AS NUMERIC.
Выясним технический нюанс: сама платформа 1С хранит свои внутренние ссылки (UUID) в базе данных именно в формате binary(16). Поэтому использование этого типа часто является «родным» для механизмов SDBL.
Посмотрим на пример создания представления с преобразованием типа:
CREATE VIEW v_1C_Compatible AS
SELECT
CAST(ID AS BINARY(16)) AS ID_Binary,
Description
FROM MySourceTable
В 1С для такого поля следует выбрать тип ДвоичныеДанные (или в некоторых случаях оставить тип по умолчанию, который предложит конструктор). Однако стоит учитывать, что работа с бинарными данными в интерфейсе 1С менее удобна, чем со строками или стандартными идентификаторами.
Проанализируем влияние системного окружения. Иногда ошибка кроется не в коде, а в способе подключения к SQL Server. Мы рекомендуем:
UPDATE-запросы с некорректным приведением типов.Мы разобрали ситуацию, когда 1С пытается интерпретировать GUID как число. Основное решение заключается в управлении метаданными. Если вы столкнулись с ошибкой SDBL:
1. Сначала попробуйте метод пересоздания: удаление таблицы из метаданных 1С -> сохранение БД -> повторное добавление. Это исправляет 90% проблем, связанных с «памятью» системы о старых типах данных.
2. Если это не помогло: используйте SQL View для принудительного приведения типа к NVARCHAR(36) на стороне сервера и работайте с ним в 1С как со строкой. Это самый надежный способ интеграции со сторонними системами (например, базами SSIS), где структура данных не контролируется платформой 1С.
3. Помните о кэше: после любых изменений структуры внешнего источника на стороне SQL Server всегда обновляйте описание таблицы в 1С, используя кнопку «Обновить описание таблиц» в форме внешнего источника данных.