Параллельное использование нескольких версий COM control (несколько версий платформ)

32 Comments

1. kolya_tlt 13.10.2017 at 17:49

   и где же ты был пару месяцев назад?

   Reply ↓
2. swimdog 13.10.2017 at 22:45

   Мы перешли на 8.3.10 и выкинули все старье

   Reply ↓
3. DenisCh 14.10.2017 at 09:03

   Это всё на сервере?
   
   А если файловые? Или код НаКлиенте работает? Тогда на каждом компе выполнять?
   
   Я правильно понимаю?

   Reply ↓
4. Team leader 14.10.2017 at 20:31

   (2) И что это означает? там коннектор не используется?

   Reply ↓
5. swimdog 15.10.2017 at 12:04

   (4) Нет, там используются коннекторы одного типа. Для одной версии не нужны такие заморочки.

   Reply ↓
6. qvvert 15.10.2017 at 23:15

   (3) на сервере

   Reply ↓
7. sisdrou 16.10.2017 at 09:01

   Спасибо. Жаль запоздалая статья. Уже проделан танец с бубном)

   Reply ↓
8. DrAku1a 17.10.2017 at 07:52

   Может, кто-то ещё всё это автоматизирует — сделает в виде обработки (которая будет автоматом регать платформу) или в виде программы-настройщика?..

   Reply ↓
9. qvvert 17.10.2017 at 17:57

   (8) Режим полного лентяя))) а что можно и сделать)))

   Reply ↓
10. Darklight 24.10.2017 at 10:29

    Боян (хоть и с более подробными картинками). Вот тут уже подымалась данная тема
    
    https://infostart.ru/public/610960/
    
    Там же и программа настройщик.
    
    Там же, в комментариях описаны возникающие, при этом, проблемы 🙁

    Reply ↓
11. qvvert 27.10.2017 at 13:38

    (10)
    
    Пардоньте, НЕ видел. Действительно те же яйца только в профиль, но добывались самостоятельно.

    Reply ↓
12. Darklight 27.10.2017 at 14:08

    (5)И что, в 8.3.10 можно писать
    

     Новый COMObject(«V8.3.COMConnector»); 

    и соединяться с любым релизом 10-й версии платформы, и 8.3.10.1212, и с 8.3.10.2561 и с 8.3.10.2685…
    
    ???

    Reply ↓
13. obsfromekb 18.12.2017 at 11:29

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

     Попытка
    ЗапуститьПриложение(«taskkill.exe /f /im dllhost.exe»,,Истина);
    КоннекторV8 = Новый COMObject(«V83.COMConnector_8.3.5»);

    Reply ↓
14. karimov_m 18.12.2017 at 12:37

    Полезно.
    
    Надо дописать, что манипуляции с добавлением компонентов и реестром (по идее) надо делать на том же сервере, где стоит сервер приложения. Конечно же, если подразумевается создание COM-объекта на сервере..

    Также интересна реализация такого приема:
    
    На сервере поднимается 2-3 COM-соединения к базе (типа пул), далее с клиентов поступают запросы/инвоки на какие-либо действия (в той базе, по которой организовался пул) и некий алгоритм обрабатывает эти запросы клиентов к другому приложению (конфигурации) по COM. Тем самым можно организовать «прослойку» (типа API) к другой базе по COM с жестко определенным функционалом + возможная выгода в использовании лицензий (пул из трех COM-соединений может обрабатывать (в порядке очереди) много больше реальных «клиентов»)

    Reply ↓
15. karimov_m 18.12.2017 at 12:50

    (13)Можно попробовать посмотреть на вкладку Activation в свойствах компонента.
    
    1. Убрать пулы
    
    2. Выбрать опцию «Must be activated in the callers context»

    Reply ↓
16. Darklight 18.12.2017 at 13:20

    (14)Идея с пулами COM-соединений на сервере (например, в фоновых заданиях), конечно, интересная, но, покуда нет эффективного решения по обмену между сессиями — она будет интересна только для узкого круга задач, где нет необходимости в интенсивном выполнении команд. Зачастую, такие медленные задачи вполне справляются самостоятельно порождая com-соединения. А по лицензиям (что важно только для длительных задач) — тут уж сами выбирайте — либо длинная очередь медленных задач, либо ультрокороткая — но с большим расходом лицензий.

    Reply ↓
17. karimov_m 18.12.2017 at 14:41

    (16)а в чем именно нужен обмен между сессиями? Синхронизацию или длительное хранение общей для всех сессий информации можно организовать в самом механизме пулов, если организовать его в виде вызовов «API пула соединений»

    Reply ↓
18. Darklight 18.12.2017 at 15:06

    (17)Работа с пулами подразумевает передачу им порции данных для выполнения и возврат результата.

    Reply ↓
19. karimov_m 18.12.2017 at 18:09

    (18) Работа с пулами подразумевает использование пулов, не более=)
    
    Сама задача — организации доступ к некой ИС(1С база1) посредством сторонней ИС (1С база2) из другой системы («1с база3» — собственно откуда идут клиенты базы «1с база1» через «1С база2») и состоит в эмуляции доступа к 1С базе 1 клиентам базы 1С база3. Только вместо прямого создания соединения из 1С база3 к 1С база1, это происходт через 1С база2 — где формируется пул. А уж какие там данные ходят и что необходимо делается — это уже отдельная логика и детали реализации.. Пулы в 1С база2 — для механизма кэширования обращений к 1С базе1. Что-то такое есть вроде в конфигурации «Интеграция» от tormozit

    Reply ↓
20. Darklight 18.12.2017 at 18:24

    (19)Вот эта логика и детали организации тут и будет узким местом!

    Reply ↓
21. karimov_m 18.12.2017 at 18:44

    (20)мм.. ну ок, пусть будет узким для вас)
    
    Как говориться, смотря как приготовить;) Речь же не о гонке производительности а в целом об архитектуре. Так то если судить то вся 1С — одно большое «узкое место», быстрее как бы напрямую делать запросы к SQL серверу..

    Reply ↓
22. Darklight 19.12.2017 at 09:29

    (21)Я свои доводы по поводу пулов COM-соединений привёл. Если считаете, что это годится в иных случаях — приведите свои.

    Reply ↓
23. karimov_m 19.12.2017 at 11:46

    (22) какие доводы? Что они «узкое место» ? Так это зависит от задачи же. Поверьте, не все задачи являются оптимизационными.

    Reply ↓
24. e-9 22.12.2017 at 16:25

    Добавил первый компонент (8.3.6.2390) успешно; ставлю второй (8.3.10.2561) — валится с ошибкой 80110802 (см. скрин), не добавляется.
    
    Что может быть не так?

    Reply ↓
25. e-9 22.12.2017 at 17:09

    (24) уточню: ОС Windows 7 64-bit

    Reply ↓
26. karimov_m 22.12.2017 at 17:35

    (25) теневое копирование включено на системном диске?
    
    После того как добавил второй компонент (и после изменений соотв.ветки реестра). перезагрузите систему. Ошибка может уйти..

    Reply ↓
27. user982256 24.05.2018 at 16:12

    (24) У меня такая же проблема, рсскажите удалось победить?

    Reply ↓
28. e-9 21.06.2018 at 18:51

    (27) убедил заказчика синхронизировать версии платформ)
    
    …моя трабла возникла на моем компе, где стоит голая семерка без обнов — мож, чего-то там просто не хватает.

    Reply ↓
29. user982256 21.06.2018 at 19:10

    (28) А я решил проблему следующим образом — насоздавал кучу (сколько надо версий, в моем случае 4) псевдономов и в реестре для каждого псевдонима (искать по clsid) сменил физический путь к dll и все взлетело. Так же обращаю внимание на то что COM компоненты должны быть зарегистрированны как серверный компонент — а то проблемы с последовательным конекторов разной версии.

    Reply ↓
30. kislitsin 31.08.2019 at 18:13

    Воспользовался вашей статьей, столкнулся с проблемой
    
    COMConnector = Новый COMObject(ИмяCOMСоединителя()); // «V83.COMConnector»
    
    по причине:
    
    -2147024769(0x8007007F): Не найдена указанная процедура.

    Не в курсе как это решить ?

    Reply ↓
31. KAPACEB.AA 17.10.2019 at 13:10

    (25)
    
    Мне удалось обойти эту ошибку используя библиотеки разной разрядности для компонент. Одну dll выбирал из каталога Program Files, а другую из Program Files x86, установив предварительно две версии клиента.

    Reply ↓
32. KAPACEB.AA 17.10.2019 at 13:11

    (27)
    
    См. комментарий (31)

    Reply ↓