Top-office11.ru

IT и мир ПК
1 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Ошибка не найдена указанная процедура

COM соединения с базами 1С на различных версиях платформы «Без перерегистрации и СМС»

Описание способа подключения к базам 1С с помощью ComConnector, на различных версиях платформы.

(5) Вот именно для этого, я и выложил исходники) Делаешь clone master ветки и дальше уже делаешь все под себя. Ну или просто руками выполняешь все действия из инструкции, много времени это не занимает, и выполнять нужно всего один раз для каждой версии.

К слову, у класса COMAdminCatalogClass имеется метод Connect, соответственно можно переписать утилиту для удаленной настройки.

Не могу понять что я делаю не так, но у меня не получается решить таким способом подключение к разным версиям из одной базы.
Например, есть следующее окружение:
— 32-х разрядные клиент-серверные версии 8.3.8.2054 (далее 8.3.8) и 8.3.9.2170 (далее 8.3.9) и соответственно две службы и две серверные базы на этих версиях.
— платформы поставлены по возрастанию версии, соответственное к 8.3.8 не подключится, так как последняя зарегистрировалась 8.3.9

Делаю по инструкции и назначаю алиас для 8.3.8 — «V83.COMConnector_838_x32», меняю путь в реестре и так далее.

Вхожу в базу на 8.3.8:
— через «V83.COMConnector_838_x32» к 8.3.8 работает подключение на клиенте и на сервере (подключение выполняется в коде &НаКлиенте и &НаСервере соответственно)
— через «V83.COMConnector» к 8.3.9 не работает . На клиенте выводится ошибка:
«The procedure entry point ?handle@ModuleLoader@core@@QAEPAUHINSTANCE__@@XZ could not be located in the dynamic link library C:Program Files (x86)1cv88.3.9.2170bincomcntr.dll.»
и далее вторая ошибка
«-2147-24769(0x8007007F) The specified module could not be found.».
На сервере только вторая ошибка.

Вхожу в базу на 8.3.9:
— через «V83.COMConnector_838_x32» к 8.3.8 не работает . На клиенте и сервере выводится «Произошла исключительная ситуация (V83.ComConnector.1): Версия компоненты ‘comcntr’ (8.3.8.2054) отличается от версии корневого модуля ‘core83’ (8.3.9.2170)
— через «V83.COMConnector» к 8.3.9 работает

В результате требуется не только «V83.COMConnector» нужной версии использовать, но и выполнять подключение из соответствующей версии клиента/сервера.
Подскажите, у кого получилось так настроить, не было ли похожей проблемы?

Кажется я понял в чем дело — система кэширует comcntr.dll (или его часть, например core83, т.к на него ругается) и при следующих обращениях использует модуль из кэша, а не получает его по имени коннектора.

Провел такой эксперимент:
— развернул платформу 8.2
— захожу в базу на 8.2, подключаюсь к 8.3.8 через «V83.COMConnector_838_x32» (в серверном коде), в 8.3.9 через «V83.COMConnector» подключение не работает
— рестарт сервера
— захожу в базу снова, но первым подключаюсь в 8.3.9 — работает, а после этого к 8.3.8 уже не работает.

Читать еще:  Ошибка прокси сервера

Таким образом в 8.2 возможно подключение к любой версии, но не к двум одновременно.
А в 8.3 так не получается, т.к. при старте сервера подгружается соответствующая версия в кэш и в дальнейшем используется она.

(10) После того как ты создал обертку V83.COMConnector, попробуй выполнить «Исправление» через Программы и компоненты, той версии через которой ты хочешь что бы был V83.COMConnector.

Сейчас попробовал одновременно подключиться к одной базе с помощью разных версий, поведение корректное.

Идея интересная, но у меня имеет место быть проблема. Если создавать COM-объекты разных версий с некоторой паузой между этим созданиями, то всё хорошо, вроде бы.
А, вот, если эту паузу не выдерживать — то возможно возникновение двух ошибок (я так и не смог понять причины и следствия когда какая ошибка возникает, скорее всего сначала первая, а при повторной попытке уже вторая)
Запускалось всё под клиентом одной или второй версии (пробовал и так и так) — файловый вариант.
Основной COM-объект был версии 8.3.10.2252, но даже если к нему обращаться как к «v83.COMConnector» то это ничего не меняло
Последовательность создания COM-объектов не влияет, но если получить первую ошибку, переставить их местами — возникает вторая ошибка
Версия клиента 1С: Предприятие так же не влияет.
Запуск в новом сеансе 1С проблему не решает.

Выполняю такой алгоритм:

Возникает первая ошибка:

При повторном запуске она повторяется

Переставляем местами создание COM-Объектов

И возникает вторая ошибка:

При повторном запуске она повторяется

Далее — если снова переставить обратно — ошибка будет повторяться

Спустя минут 15-20 всё проходит — и начинается с начала (с учётом переставленных вызовов создания COM-объектов):

Значит COM-объект где-то кешируется (платформой 1С? — мало вероятно — т.к. перезапуск клиента ничего не решает) и при попытке создать повторно (пусть и, в общем-то, другой COM-Объект) идёт обращение к старому и происходит какой-то конфликт версий.

Увы, это почти ставит крест на данной методике. Но, если одновременная (читай последовательная но в одно и то же время в пределах 20 минут) работа не требуется — описанный в статье метод будет работать.
Но, лично мне нужна была одновременная работа 🙁
Надо попробовать выполнить те же обращения, но не из 1С — если проблемы не будет, то значит это 1С кеширует (и это можно обойти — но логику работы с COM-объектом придётся выносить за пределы 1С), а если будет. то нужно что инове придумывать!

Попробовал так же с компонентами редакции 8.2:

В общем-то такая же ситуация, но ошибка всегда на ВТОРОЙ по счёту компоненте (не важно какой она версии. ) и всегда такая:

Читать еще:  Как исправить ошибку google

При этом если создавать и использовать их отдельно (посадил на разные кнопки)
То ситуация такая
1. Любую создаю — всё нормально
2. Создаю вторую — возникает ошибка
3. Создаю первую — ошибки нет
4. Создаю вторую — ошибка
5. Повторно создаю вторую — ошибки нет
6. Снова создаю вторую — ошибки нет
7. Создаю первую — ошибка
8. Создаю первую — ошибки нет
9. Создаю вторую — ошибка
10. Создаю вторую — ошибки нети

То есть первый раз создаётся нормально и если сразу создавать другой версии — будет ошибка — но при повторном создании — ошибки не будет — но она снова будет у первой, что при повторном создании так же ошибки не будет
Поэтому с v82 я написал вот так — и в общем-то оно работает

Значит компонента 8.2 не кэшируется, в отличии от 8.3 😐

Попытка же написать так же для 8.3

первый раз отработало, но повторный запуск привёл к ошибке
V83.COMConnector_8.3.10.2252:

это самая первая строка в первой попытке — и эта ошибка дальше стабильно повторялась

Попробовал работать параллельно с компонентами V82 и v82

Никаких ошибок не возникает!

Так что — как 1С (или windows) это всё обрабатывают, что возникает такой винегрет из разных ситуаций — непонятно.
Надо ещё разбираться и экспериментировать

Возможно эти проблемы чисто связаны с моей конфигурацией ОС — использую windows 8
А может дело в используемых релизах 1С: Предприятие, клиента и компонент (хотя на клиенте 8.2.19.80 я тоже попробовал — всё то же самое)

Может, у меня просто компоненты как-то неправильно установлены или какие-то заморочки с настройками COM+
Я, например, не нашёл типовых компонент в разделе COM+ как на картинках автора 🙁
Хорошо бы кто-то ещё это всё проверил бы на своих конфигурациях платформ и компонент

Точка входа не найдена в библиотеке dll

Это руководство поможет Вам, если у вас появляется сообщение об ошибке «Точка входа в процедуру не найдена в библиотеке DLL«. Эта ошибка появляется, когда программе или игре не удается найти библиотеку DLL, которая должна быть запущена. Также эта ошибка может быть из-за повреждения DLL или библиотека находится не в правильном каталоге по указанному пути. В синтаксисе ошибке, могут быть разные имена, к примеру kernel32.dll, libxml2.dll или msvcrt.dll. Очень запутанная ошибка и решение её могут загнать в тупик, но давайте разберем советы, которые помогут исправить, когда «Точка входа не найдена в библиотеке dll».

Читать еще:  Ошибка средней в эксель

Ошибка: Точка входа не найдена в библиотеке dll

Способ 1. Во первых переустановите саму программу еще раз и проверьте устранена ли проблема. Далее обновите систему Windows до последней версии. И конечно же, это может быть вирус. Воспользуйтесь антивирусным сканером .

Способ 2. Если DLL файлы повреждены, то есть смысл воспользоваться встроенными инструментами CHKDSK, SFC и DISM для восстановления системных файлов и проверки диска на ошибки. Вводите по одной команде и перезагружайте ПК, после каждого законченного процесса. Откройте командную строку от имени администратора и введите команды ниже:

  1. chkdsk /f /r /x — проверка диска на ошибки.
  2. sfc /scannow — проверка системных файлов.
  3. DISM /Online /Cleanup-Image /RestoreHealth — восстановление из образа.

Способ 2. Иногда нужно зарегистрировать заново dll файл. Для этого откройте командную строку от имени администратора и введите команду:

  • regsvr32.exe kernel32.dll

Где kernel32.dll это предполагаемый файл, который выдает ошибку. Этот способ также помогает, когда вы скопировали файл с другого ПК и его нужно зарегить в системе.

Способ 3. Попробуйте найти файл, который выдает ошибку, на другом ПК или попросите у знакомого, чтобы скинул. Ни в коем случае не скачивайте отдельный файл со сторонних источников. Пути файлов можно посмотреть в свойствах файла. Когда вы скопируйте к себе файл, то его нужно будет зарегистрировать способ выше (способ 2).

Способ 4. Не установленный пакета Visual C++, может выдавать эту ошибку. Также в некоторых случаях нужно два типа пакета Visual C++ x32-бита и x64-бита. К примеру, если у вас точка входа не найдена в библиотеке DLL и указано имя файла msvcr120.dll, то нужно установить Visual C ++ 2013. Это можно посмотреть в свойствах самого DLL файла во вкладке «Подробно». Скачайте с официально сайта Microsoft набрав определенную версию пакета в Google поиске и установите сразу два типа x32-бита и x64-бита.

Способ 5. Проверьте оперативную память на ошибки. Нажмите Win+R и введите mdsched.exe. Далее следуйте инструкциям на экране и после перезагрузки ПК начнется диагностика ОЗУ. Это руководство поможет вам диагностировать ошибки в ОЗУ .

Советы:

  1. Разгон вашего ПК может работать месяц без ошибок, а потом выдавать всякие ошибки. Откатите систему назад на заводские настройки.
  2. Если вы используете Windows XP и пытаетесь запустить Microsoft Office 2010, то вам нужно удалить пакет обновлений KB4462157 или КВ4462174.
  3. Воспользуйтесь программы для очистки реестра .
  4. Откройте «Просмотрщик событий» и найдите там ошибку похожую на ту, что выдавало вам. Можно прикинуть время, чтобы сократить труд.
Ссылка на основную публикацию
Adblock
detector