Создание Таблицы значений в СОМ-объекте #778135

Добрый день. Подскажите, как правильно создать Таблицу значений в Сом-соединении к базе 1С? Пытаюсь так: " ... мОбъектПодключение - это сом-соединение к базе. Рабочее. ТаблицаКодов = мОбъектПодключение.NewObject("ТаблицаЗначений"); Ошибка возникает уже на строке

как насчёт КС = мОбъектПодключение.NewObject("КвалификаторыСтроки", 20)?

Используй внешнийОтчет

У вас там нету под рукой 1С-ника? Чтобы сервис поднял в 1С и юзайте его, а не неудобный уже сейчас COM.

Когда надо писать много кода через ком-объект - интереснее в приемнике реализовать метод, и вызывать его из источника.

+ через NewObject вроде не все русские именования объектов поддерживаются. Натыкался на подобное поведение, можно англ. синоним в сп посмотреть и использовать его

Так отработало, правильно. Теперь ругается чуть дальше: или

Объясни науя тебе нуна эти "ОписаниеТипов" и "КвалификаторыСтроки"?

+ Когда можно данные переносить прекрасно без этого, 1С же не язык/среда со строгой типизацией. Тут типизация вариативная/динамическая практически "утиная".

Пытаюсь создать таблицу значений, которую передам в запрос к сом-соединению. Таблица значений передаваемая в запрос как параметр должна быть с описанными типами колонок. Глобальней: С другой базы необходимо получить остатки по конкретному перечню номенклатуры. В таблице передаваемой как параметр будут находиться коды этой самой номенклатуры

для только кодов ТЗ в запрос не надо, хватит СЗ

+

Удалось достигнуть требуемого результата в запросе, сформировав в соединении массив и заполнив его требуемой номенклатурой. Массив передан в запрос как параметр. Спасибо Всем за помощь.

Можно еще выполнить в приемнике запрос со стороны источника, и выгрузить его результат в тз. Что то типа: - выгрузить в тз и очистить строки. Дикий костыль, но кодить меньше)

верно, только запрос и массив параметр создаются как мОбъектПодключение.NewObject("Массив"); мОбъектПодключение.NewObject("Запрос");

На C# пишем?

+ Или 7шник?

Скорее начинающий познавать прелести общения через сом. Подозреваю, что Тип("строка") тоже должен был быть создан в коннекторе, или чего там используете, но изначально изврат знатный. Квалификаторы создавал пару раз, но кажется причина была в просто интересе, не врет ли сп

имхо, все телодвижения лучше выполнять на стороне сервера COM по схеме: 1) Создаем и инициализируем  Com- объект ; 2) Отправляем на вход параметры (например сериализованное ХЗ с примитивными типами, ужатое). Входом может быть, например, экспортная функция внешней обработки. 3) На стороне сервера -отрабатывает функция входа, возвращает клиенту результат (опять же как вариант сериализованное ужатое ХЗ)

такой мутор из за создания сом массива.. неоправданно это. А делать "универсальную" процедуру еще муторней, и выхлопа от нее никакого, т к при каждом обращении с новыми условиями придется универсальное универсализировать еще сильнее

нет. Это не процедура, а механизм, причем очень простой. Выигрыш: 1) Значительно упрощается код, так как не смешиваются локальный и COM контексты. NewObject и String - не столь существенно, но тоже. 2) Простота отладки.  Отлаживать выполнение можно напрямую в COM-объекте, заэмулировав вызов, что достаточно просто, и не нарушает работоспособности "боевой" обработки. 3) Скорость выполнения - теоретически множественное создание COM-объектов, и постоянный обмен по COM, а если еще клиент и сервер разнесены физически... Собственно, уменьшение траффика между клиентом и сервером (в данном случае - в контексте COM)

"Входом может быть экспортная функция обработки" я перепутал функцию с процедурой? Отладка кома проста как овсянка, "эмулировать" имеется ввиду сам вызвал сам принял? Не будет учтен контекст внешнего соединения, хотя мелочь да - что там отлаживать то. Трафик в наше время - хрень, связь либо есть и тогда трафик не имеет значения(в пределах разумного, гнуху передавать не будем) либо связи нет, тогда трафик значения тоже не имеет. Единственно, если базы по gprs только, то да. Может не понял фишки механизма, но из особенного пока увидел только хз, которая передается как и любая строка из базы в базу

никакой фишки нет. Есть только принцип - код COM-объекта выполняется в собственном контексте. Отсюда - все остальные преимущества. Как этот принцип будет реализован - дело вообще десятое. В 1С (лично для меня) самым оптимальным оказался механизм внешних обработок. Вообще, нет желания спорить, я просто вынес свое мнение в качестве обмена опытом (вдруг кому пригодится).

Раньше делал через "ручную" сериализацию с обработкой на стороне сервера, да, как говорите, потом забил, только прямой ком, только хардкор, проверки? Только на заполненность переменных и результатов запросов(грубо говоря), код должен работать так, как его пишут и не выдавать неожиданных значений. В общем выдумать чего то универсального не получилось, чтобы отдал и забыл - не бывает такого, убежден. Я понимаю, что опыт, его и хотелось узнать :) помечталось что и правда есть некое "ХЗ" которое решит все хз) спасибо за несколько минут надежды ;P