Powershell и 1С через COM #742187

Добрый день! Хочу запросом через повершел вытянуть из 1С данные. Подключаюсь через  com. Соединение проходит, но не пойму как создать запрос. Ругается на отсутствие метода NewObject. Нагуглил , что "Для "V81.COMConnector" павершелл находит библиотеку типов, поэтому для COMConnector позднее связывание можно использовать, а для COM-соединения уже фигушки - только ручками через рефлексию..." и примеры Примеры работы, но попытки создать именно запрос ни к чему не привели. Может кто знает как решить мою проблему?

Вот такое не работает - $cats = [System.__ComObject].InvokeMember("Новый Запрос",[System.Reflection.BindingFlags]::GetProperty,$null,$connection,$null)

Извращенцы Вообще проще использовать Внешние отчеты. Сначала отлаживаешь под отладчиком и прочими приятностями, а затем вызываешь уже по ком Добавлю что V77.Application является внешним сервером автоматизации, а это значит что вызов происходит из другого процесса и соответственно все данные маршалицируются и сериализуются. При этом скорость каждого вызова выполняется очень медленно. Выводя весь код в обработку он выполняется в процессе сервера, что значительно быстрее. Кроме того 1С использует в запросах принцип замыкания (использование переменных процедуры, модуля итд). Так, что используя внешние отчеты упрощается тестирование, увеличивается скорость обработки, и увеличивается гибкость для запросов. Кроме того можно вычислять и произвольный код используя шаблон

А причем тут ole? Я ж через com хочу

А в чем разница между оле и сом? Вообщето COM это поддержка интерфейса IUnknown. OLE уже iDispatch. OLE Automation — технология компании Microsoft, позволяющая обращаться к COM-объектам из интерпретаторов скриптовых языков, таких, как VBScript (на настоящий момент поддержка обращений к OA-объектам есть в Windows-версиях всех популярных скриптовых языков).

Прошу прощеня, почудилась семерка. Но для восьмерки тоже проще использовать внешние отчеты например

Там как раз все как  у меня. Только в C# NewObject работает, а в повершелле нет. Я как раз же переписываю решение с си шарпа на повершелл.

Я тебе дал ссылку как проще работать через внешний отчет. Там кстати не C# а VB. Внешний отчет проще отлаживать.

Вот , спасибо огромнейшее!!!!!!

мыши плакали, кололись, но продолжали жрать кактус

Я же не спорю что ты прав - но мне в данном случае хочется сделать именно так:)

В таком виде как это полный изврат. Но стоит перенести все нагромождения в отдельные функции, и код становится вполне вменяемым:

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

> А еще лучше прямой доступ к SQL Проще да, но не лучше.

Обоснуй

"проще" - зачем заморачиваться и писать нормально API для отчетов, зафигачим прямой доступ к таблицам, благо любой внешний составитель отчетов умеет подключаться к SQL. "не лучше" - начнем с нарушения лиц.соглашения, затем необходимость добавлять (и администрировать) отдельного SQL пользователя, отслеживать структуру БД (добавили поле в SQL-запрос, через год в 1С добавили ему "Удалить", а через год удалили и узнали что уже два года отчет показывает херню) и т.д.

Структура может меняться в разных версиях платформы. При записи есть риск повредить данные, если не учесть составные структуры (итоги, агрегаты).

Я использовал из 1С запись в регистры сведений используя Merge. Разница по скорости при работе с миллионными прайсами такая, что ... Но в основном нужно чтение, а то что без чтения лучше организовывать через Web или HTTP сервисы