При работе с внешними базами данных из среды 1С программисты часто сталкиваются с необходимостью прямого управления данными через механизмы ADO (ActiveX Data Objects). Однако использование COM-объектов требует особой тщательности при передаче типов данных. Одной из самых коварных ошибок является исключительная ситуация: «Произошла исключительная ситуация (Provider): Член группы не найден» (или "Member not found").
В этой статье мы подробно разберем, почему возникает эта ошибка при попытке записи в Recordset, и как правильно организовать обмен данными между 1С и внешней СУБД, чтобы избежать конфликтов типов.
Рассмотрим типичный сценарий: программист пытается добавить новую запись во внешнюю таблицу, используя драйвер ADO. Для поиска необходимых идентификаторов (внешних ключей) используются встроенные средства 1С — механизм «Внешние источники данных».
Проанализируем фрагмент кода, который вызывает ошибку:
Конект = Новый ComОбъект("ADODB.Connection");
Конект.ConnectionString = "DRIVER={SQL Server};SERVER=...;DATABASE=...;";
Конект.Open();
Recordset = Новый COMОбъект("ADODB.Recordset");
Recordset.CursorLocation = 2; // adUseClient
RecordSet.Open("__Int", Конект, 2, 3); // adOpenDynamic, adLockOptimistic
RecordSet.AddNew();
// Запись обычного значения проходит успешно
RecordSet.Fields("value").Value = value;
// ОШИБКА ЗДЕСЬ:
RecordSet.Fields("id_ord").Value = ВнешниеИсточникиДанных.БазаСтудент.Таблицы.dbo_Order.НайтиПоПолю("id_ord", id_ord);
RecordSet.Update();
RecordSet.Close();
Конект.Close();
На первый взгляд код выглядит логично, но именно в строке присвоения значения полю id_ord происходит сбой. Проанализируем причину возникновения исключения.
Основная проблема кроется в том, что метод НайтиПоПолю(), применяемый к таблице внешнего источника данных в 1С, возвращает не число и не строку, а объект типа ВнешнийИсточникДанныхТаблицаСсылка.
Почему это приводит к ошибке:
ADODB.Recordset «общается» с операционной системой и драйвером базы данных на языке стандартных типов OLE (Integer, String, Boolean, Double, GUID). Он не знает, как обрабатывать внутренние объекты 1С, такие как ссылки.Value поля Fields, интерфейс ADO пытается найти у переданного объекта стандартные свойства или методы, чтобы преобразовать его в понятный формат. Не находя их, он выдает системную ошибку «Член группы не найден».Для исправления ситуации нам необходимо передать в ADO только само значение ключа (например, число или уникальный идентификатор), которое хранится «внутри» ссылки 1С. Рассмотрим, как изменить код по шагам.
Сначала мы получаем ссылку, а затем обращаемся к ее реквизиту (полю первичного ключа):
// 1. Находим ссылку на объект во внешнем источнике
СсылкаЗаказ = ВнешниеИсточникиДанных.БазаСтудент.Таблицы.dbo_Order.НайтиПоПолю("id_ord", id_ord);
// 2. Проверяем, что ссылка не пустая (необязательно, но полезно для стабильности)
Если Не СсылкаЗаказ.Пустая() Тогда
// 3. ПРИСВАИВАЕМ ЗНАЧЕНИЕ ПОЛЯ ССЫЛКИ, А НЕ САМУ ССЫЛКУ
RecordSet.Fields("id_ord").Value = СсылкаЗаказ.id_ord;
КонецЕсли;
В данном случае СсылкаЗаказ.id_ord вернет обычное Число, которое ADO легко передаст в SQL-сервер. Аналогично следует поступить и с остальными полями, использующими поиск через внешние источники.
Если база данных уже подключена к конфигурации 1С через механизм «Внешние источники данных», использование низкоуровневого соединения через ADODB.Connection часто является избыточным. Разберем, как сделать ту же самую запись, используя только средства 1С. Это гораздо надежнее, так как платформа сама берет на себя трансляцию типов данных.
Посмотрим на пример записи через МенеджерЗаписи:
// Создаем менеджер записи для таблицы
Менеджер = ВнешниеИсточникиДанных.БазаСтудент.Таблицы.ИмяНужнойТаблицы.СоздатьМенеджерЗаписи();
// Заполняем поля. Здесь 1С сама поймет, что Ссылка должна превратиться в ID в базе SQL
Менеджер.value = value;
Менеджер.id_ord = ВнешниеИсточникиДанных.БазаСтудент.Таблицы.dbo_Order.НайтиПоПолю("id_ord", id_ord);
Менеджер.id_af = ВнешниеИсточникиДанных.БазаСтудент.Таблицы.dbo_AdditField.НайтиПоПолю("id_af", id_af);
// Выполняем запись
Попытка
Менеджер.Записать();
Исключение
Сообщить("Ошибка при записи во внешний источник: " + ОписаниеОшибки());
КонецПопытки;
Преимущества этого метода:
Дата 1С в формат даты SQL).Если использование ADODB для вас критично (например, вы вызываете сложную хранимую процедуру или используете специфические возможности драйвера), следуйте этим правилам:
1. Всегда проверяйте типы через отладчик. Если вы видите в значении переменной что-то вроде {"#",5747...} или ВнешнийИсточникДанныхТаблицаСсылка..., знайте — это объект 1С, и напрямую в Recordset его передавать нельзя.
2. Приведение к примитивам. Используйте функции Число(), Строка(), Формат() для принудительной конвертации данных перед отправкой в COM-объект. Это гарантирует, что драйвер получит данные в стандартном виде.
3. Работа с NULL. Помните, что в базах данных значение NULL — это не то же самое, что Неопределено или пустая ссылка в 1С. Для передачи NULL через ADO используйте Null:
Если ЗначениеНеЗаполнено(МояПеременная) Тогда
RecordSet.Fields("MyField").Value = Null;
Иначе
RecordSet.Fields("MyField").Value = МояПеременная;
КонецЕсли;
4. Использование параметров команды. Вместо прямого редактирования Recordset, мы рекомендуем использовать ADODB.Command с параметрами (Parameters.Append). Это защищает от ошибок типов и SQL-инъекций, так как вы явно указываете тип параметра (например, adInteger или adVarChar).
Проанализировав ситуацию, мы выяснили, что ошибка «Член группы не найден» — это классический индикатор того, что 1С пытается «пропихнуть» свой сложный внутренний объект туда, где ожидается простое значение. Внимательное отношение к типам данных при использовании COM-технологий — залог стабильной работы ваших интеграций.