В файловом варианте все взлетело без проблем… А вот в серверном начались проблемы. Решениям этих проблем и посвящается данная статья.
При миграции приложений с 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 по дефолту)…
Для адекватной работы нам необходимо дать права на чтение по ключу реестра HKLMSOFTWAREODBCODBC.INI для everyone или конкретного пользователя.
Потом зарегистрировать DSN
Ну и провести подключение к Adodb.Connection:
DBConn = Новый COMОбъект("ADODB.Connection");
DBConn.Open("DSN=ODBC_DBase;Dbq=" + Path + ";");
После этого подключение взлетело и по аналогии можно подключить любой драйвер.
Спасибо за внимание 😉
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
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;»»;»);
#КонецЕсли
Сталкивался с «похожей» ситуацией, в том смысле, что нужно учитывать не только «ГДЕ» выполняется но и «ПОД КЕМ»
(1) Kyrales, Microsoft.ACE.OLEDB.12.0 — так же не хотел работать =)))
Дело не какой именно драйвер, а в АДО в целом.
Ваш вариант у меня не взлетел бы =))
И если вы не заметили — это в управляемом приложении…
Процедура у меня полностью выполняется &НаСервере, Хоть в файловом варианте, хоть в серверном и от ширины клиента тут ничего не зависило… Дело в том, где находится серв, где компилируется код…
бывает приходиться заниматься странными вещами. Спасибо за работающий способ
(4) PiccaHut001, всегда рад, если кому то помогло решить проблему или натолкнуло на ее решение =))) 😉
Действительно бывает такое, что вроде бы скриптуешь в 1С, а на самом деле пишешь на SQL и админишь сервера =))).
Темная информация, надо запомнить!
А что мешало выполнять код на стороне клиента? Я давно с таким уже сталкивался и решал вопрос выполнением &НаКлиенте
(7) oberonm, Вот представьте себе большой холдинг, несколько заводов и главное управление, весь учет в одинэссе…
На каждом заводе свой терм.сервер с доменной структурой…
Проще, да и целесообразней на одном сервере решить проблему, чем на каждом терм сервере ставить дрова нужных Одбц…
Да и на клиенте не всегда поюзаешь… В случае регламентного задание, например. В моем случае как раз это и был регламент.
Однако у меня с парадоксом ваш вариант не взлетел, хотя и вообще никакой не взлетел. Решил переписывать на клиент всё.
2 недели ковыряния коту под хвост (
(9) Ibrogim, а какая ошибка возникала при подключении?
(9) Ibrogim,
Я с парадоксом игрался лет 5 назад, когда писал дипломный проект (1С + Проект на Делфях)
Взлетело без проблем. Но у меня точкой синхронизации выступало приложение на делфях а не 1с. (не 1с коннектор использовал а приложение)
Не знаком с архитектурой Paradox-а. Но, видимо проблема с сервисной стороной БД. Есть ли запущенная служба «слушающая» обращение к базе? Возможно БД у вас работает только с клиентскими вызовами?