Внешние источники данных: не сохраняется ссылка реквизита справочника типа "... внешний источник данных"
Собственно суть вопроса в теме.
Платформа: 1С:Предприятие 8.3 (8.3.22.1603)
Создана таблица во внешнем источнике SQL, соединение настроено, работает. При записи объекта таблицы, в SQL информация обновляется.
Создан справочник, одному из реквизитов "Реквизит1" установлен тип "ВнешнийИсточникДанныхТаблицаСсылка.СправочнаяИнформация.Контрагенты", на форму выведено поле.
В режиме предприятия на форме справочника выбираю значение этого реквизита и записываю элемент.
Открываю эту же форму справочника, а поле "Реквизит1" - пустое!
Перечитал всю документацию, но какой-то специфики про связь ссылки на внешний источник данных не заметил.
Прошу помочь, указать какие-то материалы, где объяснено, как организовывать такую связку.
Платформа: 1С:Предприятие 8.3 (8.3.22.1603)
Создана таблица во внешнем источнике SQL, соединение настроено, работает. При записи объекта таблицы, в SQL информация обновляется.
Создан справочник, одному из реквизитов "Реквизит1" установлен тип "ВнешнийИсточникДанныхТаблицаСсылка.СправочнаяИнформация.Контрагенты", на форму выведено поле.
В режиме предприятия на форме справочника выбираю значение этого реквизита и записываю элемент.
Открываю эту же форму справочника, а поле "Реквизит1" - пустое!
Перечитал всю документацию, но какой-то специфики про связь ссылки на внешний источник данных не заметил.
Прошу помочь, указать какие-то материалы, где объяснено, как организовывать такую связку.
Прикрепленные файлы:
По теме из базы знаний
- Регистрация запуска обработок во внешнем источнике данных
- Конфигурация Flowcon: Набор инструментов для управления задачами, проектами и бизнесом в 1С
- Обработка для адаптивного переноса данных между базами через XML
- Описание формата контейнера 1С (CF, EPF, ERF, CFE) с помощью БНФ. Предлагается внешняя компонента на С
- Заметки по Конвертации данных 2.1
Найденные решения
После экспериментов нашёл причину такого поведения платформы:
Колонка ID в SQL имеет тип uniqueidentifier, что является аналогом УникальногоИдентификатора в 1С.
Далее, из описания на its.1c.ru я нашёл следующее:
При записи уникального идентификатора в поле таблицы внешнего источника данных платформа «1С:Предприятие» выполняет перестановку данных уникального идентификатора. Таким образом, данные во внешнюю базу данных будут помещаться в измененном виде. При чтении уникального идентификатора данные переставляются обратно. Поэтому, при записи/чтении уникальный идентификатор сохраняет свое исходное значение.
Таким образом, в момент записи объекта ВИД происходит замена формата идентификатора!
Для примера:
a0e55759-35f1-400c-8169-e5edbc2486ba - значение поля в 1С;
ede56981-24bc-ba86-400c-35f1a0e55759 - значение поля в SQL.
Поэтому, при открытии формы 1С во внешнем источнике ищет по значению "a0e55759-..." и конечно же не находит его.
Не знаю, фитча ли это, или ошибка, но "При чтении уникального идентификатора данные переставляются обратно." - странно отрабатывает.
Колонка ID в SQL имеет тип uniqueidentifier, что является аналогом УникальногоИдентификатора в 1С.
Далее, из описания на its.1c.ru я нашёл следующее:
При записи уникального идентификатора в поле таблицы внешнего источника данных платформа «1С:Предприятие» выполняет перестановку данных уникального идентификатора. Таким образом, данные во внешнюю базу данных будут помещаться в измененном виде. При чтении уникального идентификатора данные переставляются обратно. Поэтому, при записи/чтении уникальный идентификатор сохраняет свое исходное значение.
Таким образом, в момент записи объекта ВИД происходит замена формата идентификатора!
Для примера:
a0e55759-35f1-400c-8169-e5edbc2486ba - значение поля в 1С;
ede56981-24bc-ba86-400c-35f1a0e55759 - значение поля в SQL.
Поэтому, при открытии формы 1С во внешнем источнике ищет по значению "a0e55759-..." и конечно же не находит его.
Не знаю, фитча ли это, или ошибка, но "При чтении уникального идентификатора данные переставляются обратно." - странно отрабатывает.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
После экспериментов нашёл причину такого поведения платформы:
Колонка ID в SQL имеет тип uniqueidentifier, что является аналогом УникальногоИдентификатора в 1С.
Далее, из описания на its.1c.ru я нашёл следующее:
При записи уникального идентификатора в поле таблицы внешнего источника данных платформа «1С:Предприятие» выполняет перестановку данных уникального идентификатора. Таким образом, данные во внешнюю базу данных будут помещаться в измененном виде. При чтении уникального идентификатора данные переставляются обратно. Поэтому, при записи/чтении уникальный идентификатор сохраняет свое исходное значение.
Таким образом, в момент записи объекта ВИД происходит замена формата идентификатора!
Для примера:
a0e55759-35f1-400c-8169-e5edbc2486ba - значение поля в 1С;
ede56981-24bc-ba86-400c-35f1a0e55759 - значение поля в SQL.
Поэтому, при открытии формы 1С во внешнем источнике ищет по значению "a0e55759-..." и конечно же не находит его.
Не знаю, фитча ли это, или ошибка, но "При чтении уникального идентификатора данные переставляются обратно." - странно отрабатывает.
Колонка ID в SQL имеет тип uniqueidentifier, что является аналогом УникальногоИдентификатора в 1С.
Далее, из описания на its.1c.ru я нашёл следующее:
При записи уникального идентификатора в поле таблицы внешнего источника данных платформа «1С:Предприятие» выполняет перестановку данных уникального идентификатора. Таким образом, данные во внешнюю базу данных будут помещаться в измененном виде. При чтении уникального идентификатора данные переставляются обратно. Поэтому, при записи/чтении уникальный идентификатор сохраняет свое исходное значение.
Таким образом, в момент записи объекта ВИД происходит замена формата идентификатора!
Для примера:
a0e55759-35f1-400c-8169-e5edbc2486ba - значение поля в 1С;
ede56981-24bc-ba86-400c-35f1a0e55759 - значение поля в SQL.
Поэтому, при открытии формы 1С во внешнем источнике ищет по значению "a0e55759-..." и конечно же не находит его.
Не знаю, фитча ли это, или ошибка, но "При чтении уникального идентификатора данные переставляются обратно." - странно отрабатывает.
(34)
Тоже заметил, что 1С по-своему конвертирует SQL-ные binary(16), в которых хранится ссылка, в 1Сный УникальныйИдентификатор. Если сделать конвертацию binary(16) в UNIQUEIDENTIFIER в запросе SQL - то получатся те самые перестановки, которые описаны в ИТС.
Для эксперимента взял Ваш же пример ГУИДов
На стороне SQL это создало запись в таблице справочника _Reference47 (_IDRRef - это Ссылка binary(16), а в последней колонке запроса я сделал конвертацию binary(16) в uniqueidentifier)
Запрос вернул
Т.е. УникальныйИдентификатор("a0e55759-35f1-400c-8169-e5edbc2486ba") в базе SQL хранится в форме binary(16) 0x8169E5EDBC2486BA400C35F1A0E55759, а при конвертации в SQL-запросе в uniqueidentifier выдает EDE56981-24BC-BA86-400C-35F1A0E55759. Иначе говоря, 1С-овский a0e55759-35f1-400c-8169-e5edbc2486ba стал SQL-ным EDE56981-24BC-BA86-400C-35F1A0E55759
a0e55759-35f1-400c-8169-e5edbc2486ba - значение поля в 1С;
ede56981-24bc-ba86-400c-35f1a0e55759 - значение поля в SQL.
ede56981-24bc-ba86-400c-35f1a0e55759 - значение поля в SQL.
Тоже заметил, что 1С по-своему конвертирует SQL-ные binary(16), в которых хранится ссылка, в 1Сный УникальныйИдентификатор. Если сделать конвертацию binary(16) в UNIQUEIDENTIFIER в запросе SQL - то получатся те самые перестановки, которые описаны в ИТС.
Для эксперимента взял Ваш же пример ГУИДов
ТестЭлемент = Справочники.Делми.СоздатьЭлемент();
ГУИД = Новый УникальныйИдентификатор("a0e55759-35f1-400c-8169-e5edbc2486ba");
Ссылка = Справочники.Делми.ПолучитьСсылку(ГУИД);
ТестЭлемент.УстановитьСсылкуНового(Ссылка);
ТестЭлемент.Наименование = "Принудительный ГУИД";
ТестЭлемент.Записать();На стороне SQL это создало запись в таблице справочника _Reference47 (_IDRRef - это Ссылка binary(16), а в последней колонке запроса я сделал конвертацию binary(16) в uniqueidentifier)
SEL ECT [_IDRRef]
,[_Description]
,CONVERT(UNIQUEIDENTIFIER,[_IDRRef]) as UU
FR OM [dbo].[_Reference47]Запрос вернул
_IDRRef _Description UU
0x8169E5EDBC2486BA400C35F1A0E55759 Принудительный ГУИД EDE56981-24BC-BA86-400C-35F1A0E55759Т.е. УникальныйИдентификатор("a0e55759-35f1-400c-8169-e5edbc2486ba") в базе SQL хранится в форме binary(16) 0x8169E5EDBC2486BA400C35F1A0E55759, а при конвертации в SQL-запросе в uniqueidentifier выдает EDE56981-24BC-BA86-400C-35F1A0E55759. Иначе говоря, 1С-овский a0e55759-35f1-400c-8169-e5edbc2486ba стал SQL-ным EDE56981-24BC-BA86-400C-35F1A0E55759
(35) И вдогонку, может кому пригодится. Исходные данные с принудительным УникальнымИдентификатором те же.
Этот запрос вернет из хранимой в БД Ссылки-binary(16) оба представления ГУИДа: и SQL-ный, и 1С-овский:
SEL ECT [_IDRRef]
,CAST([_IDRRef] as uniqueidentifier) GUID_SQL
,CAST(CAST(REVERSE(SUBSTRING( [_IDRRef], 9, 8)) AS binary(8))+ SUBSTRING([_IDRRef], 1, 8) as uniqueidentifier) GUID_1C
FR OM [dbo].[_Reference47]Этот запрос вернет из хранимой в БД Ссылки-binary(16) оба представления ГУИДа: и SQL-ный, и 1С-овский:
_IDRRef GUID_SQL GUID_1C
0x8169E5EDBC2486BA400C35F1A0E55759 EDE56981-24BC-BA86-400C-35F1A0E55759 A0E55759-35F1-400C-8169-E5EDBC2486BA
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот