gifts2017

Моя война с Adodb.connection "Microsoft.Jet.OLEDB.4.0" на 64-х битных серверных ОС (86х)

Опубликовал Alexander Shvets (Alexander.Shvets) в раздел Программирование - Практика программирования

На тонком клиенте в управляемом приложении появилась потребность работы с Adodb.Connection. В моем случае это был драйвер "Microsoft.Jet.OLEDB.4.0".

В файловом варианте все взлетело без проблем... А вот в серверном начались проблемы. Решениям этих проблем и посвящается данная статья.

При миграции приложений с MSSQL 2005 и Server 2003 в MSSQL 2008 x64 и Server 2008 x64, я столкнулся с проблемой с ODBC-соединения. Приложение использует системный DSN для подключения к ODBCНастройки были идентичны , в пределах менеджера ODBC работал.

Оказывается, что 32-разрядные приложения не видят уведомления о доставке данных созданных в 64-битном менеджере ODBC, и будет выполнена одна из ошибок описаных ниже.

32-разрядный ODBC Manager находится в C: \ Windows \ SysWOW64 \ odbcad32.exe

При выполнении кода подключения на сервере

DBConn = Новый COMОбъект("ADODB.Connection");
DBConn.Open("Provider=Microsoft.Jet.OLEDB.4.0;" +
"Data Source=" + Path + ";" +
"Extended Properties=""DBASE IV;"";");

Возникала исключительная ситуация 

(Microsoft OLE DB Provider for ODBC Drivers): [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified

Причем на файловой базе все происходило без проблем.

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

Суть проблемы и решение:

Оказывается Сервер на котором крутился SQL не хотел давать доступ напрямую к реестру и *.dll, которые находились удаленно, а пытался поднять эти библиотеки не пользователь терминального сервера на клиенте, а пользователь от которого была запущена служба сервера 1С на SQL-e (USR1CV82 по дефолту)...

Для адекватной работы нам необходимо дать права на чтение по ключу реестра HKLM\SOFTWARE\ODBC\ODBC.INI для everyone или конкретного пользователя.

http://pikucha.ru/iak8Z/thumbnail/ODBC+regedit.jpeg

Потом зарегистрировать DSN

http://pikucha.ru/iak9o/thumbnail/ODBC+manager.jpeg

Ну и провести подключение к Adodb.Connection:

DBConn = Новый COMОбъект("ADODB.Connection");
DBConn.Open("DSN=ODBC_DBase;Dbq=" + Path + ";");


После этого подключение взлетело и по аналогии можно подключить любой драйвер. 

Спасибо за внимание ;) 

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Олег Каратаев (Kyrales) 21.02.13 08:40
DBConn = Новый COMОбъект("ADODB.Connection");

#Если Сервер Тогда
DBConn.Open("Provider=Microsoft.ACE.OLEDB.12.0;" +
"Data Source=" + Path + ";" +
"Extended Properties=""DBASE IV;"";");
#Иначе
DBConn.Open("Provider=Microsoft.Jet.OLEDB.4.0;" +
"Data Source=" + Path + ";" +
"Extended Properties=""DBASE IV;"";");
#КонецЕсли
2. Ловыгин Антон (wunderland) 21.02.13 11:19
Сталкивался с "похожей" ситуацией, в том смысле, что нужно учитывать не только "ГДЕ" выполняется но и "ПОД КЕМ"
3. Alexander Shvets (Alexander.Shvets) 21.02.13 13:48
(1) Kyrales, Microsoft.ACE.OLEDB.12.0 - так же не хотел работать =)))
Дело не какой именно драйвер, а в АДО в целом.
Ваш вариант у меня не взлетел бы =))

И если вы не заметили - это в управляемом приложении...

Процедура у меня полностью выполняется &НаСервере, Хоть в файловом варианте, хоть в серверном и от ширины клиента тут ничего не зависило... Дело в том, где находится серв, где компилируется код...
4. John Smith (PiccaHut001) 21.02.13 18:00
бывает приходиться заниматься странными вещами. Спасибо за работающий способ
5. Alexander Shvets (Alexander.Shvets) 21.02.13 18:18
(4) PiccaHut001, всегда рад, если кому то помогло решить проблему или натолкнуло на ее решение =))) ;)
Действительно бывает такое, что вроде бы скриптуешь в 1С, а на самом деле пишешь на SQL и админишь сервера =))).
6. Алексей Роза (DoctorRoza) 21.02.13 20:14
Темная информация, надо запомнить!
7. Oberonm (oberonm) 22.02.13 08:09
А что мешало выполнять код на стороне клиента? Я давно с таким уже сталкивался и решал вопрос выполнением &НаКлиенте
8. Alexander Shvets (Alexander.Shvets) 22.02.13 12:20
(7) oberonm, Вот представьте себе большой холдинг, несколько заводов и главное управление, весь учет в одинэссе...
На каждом заводе свой терм.сервер с доменной структурой...
Проще, да и целесообразней на одном сервере решить проблему, чем на каждом терм сервере ставить дрова нужных Одбц...

Да и на клиенте не всегда поюзаешь... В случае регламентного задание, например. В моем случае как раз это и был регламент.
9. Иван Титов (Ibrogim) 30.09.14 08:13
Однако у меня с парадоксом ваш вариант не взлетел, хотя и вообще никакой не взлетел. Решил переписывать на клиент всё.
2 недели ковыряния коту под хвост (
10. Alexander Shvets (Alexander.Shvets) 30.09.14 15:36
(9) Ibrogim, а какая ошибка возникала при подключении?
11. Alexander Shvets (Alexander.Shvets) 30.09.14 15:43
(9) Ibrogim,

Я с парадоксом игрался лет 5 назад, когда писал дипломный проект (1С + Проект на Делфях)
Взлетело без проблем. Но у меня точкой синхронизации выступало приложение на делфях а не 1с. (не 1с коннектор использовал а приложение)

Не знаком с архитектурой Paradox-а. Но, видимо проблема с сервисной стороной БД. Есть ли запущенная служба "слушающая" обращение к базе? Возможно БД у вас работает только с клиентскими вызовами?
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа