Стандартное 64-битное соединение ODBC Coldfusion 9.0.1 и Oracle 11g приводит к «несоответствию архитектуры» - PullRequest
5 голосов
/ 10 августа 2011

У меня есть недавно собранная 64-битная версия Windows Server 2008 R2, на которой я установил 64-битную версию Coldfusion 9 Standard.Я обновил и исправил его до самой последней версии CF.У меня также был установлен 64-битный клиент Oracle 11g (11.1.0.7.0).Я создал системный DSN, используя 64-разрядный администратор источника данных ODBC в Windows, и могу успешно проверить соединение с источником данных.

Однако все эти установки прошли без проблем, когда я добавилИсточник данных в администраторе Coldfusion Я получаю сообщение об ошибке:

Не удалось проверить соединение для источника данных: myDatabaseName

java.sql.SQLException: [Macromedia] [Драйвер JDBC SequeLink] [Разъем ODBC] внутренняя ошибка: указанный DSN содержит несоответствие архитектуры между драйвером и приложением. Основная причина была в том, что: java.sql.SQLException: [Macromedia] [SequeLink JDBC Driver] [ODBC Socket] внутренняя ошибка: указанный DSN содержит несоответствие архитектурымежду драйвером и приложением

Мне трудно понять, из-за чего происходит это несоответствие архитектуры, поскольку устройство полностью 64-разрядное.При рассмотрении всех запущенных процессов я вижу, что некоторые связанные процессы CF выполняются в 32-разрядных системах (процессы, связанные с Verity, SOLR и CFDotNetSVC).Я не уверен, могли ли бы они вызвать эту проблему, но я затрудняюсь объяснить, было бы это несоответствие иначе.

У кого-нибудь есть идеи?

Ответы [ 4 ]

7 голосов
/ 11 августа 2011

По совету Дэна я взял драйвер JDBC из Oracle здесь:

http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-111060-084321.html

Затем я переместил JAR (в моем случае ojdbc6.jar) и добавил его в путь к классу Coldfusion.

Определить правильные настройки для использования источника данных в Coldfusion было немного сложнее, но вот настройки, с которыми я в итоге поехал:

JDBC URL: jdbc:oracle:thin:@//dbsrv.mydomain.com:1521/myDB.world
Driver Class: oracle.jdbc.driver.OracleDriver
Driver Name: Oracle Thin Driver

Затем имя пользователя и пароль для БД.

Конечно, это сработало как шарм.

Дэн, я хочу поставить тебе галочку, потому что ты определенно поставил меня в правильном направлении, но я могу отметить только одно правильное.

4 голосов
/ 10 августа 2011

Полагаю, вам нужно либо перейти на 32-разрядные драйверы , либо использовать собственные драйверы JDBC для успешного подключения к Oracle.Мое предложение состояло бы в том, чтобы пойти по маршруту JDBC и подключиться напрямую через собственный драйвер Oracle JDBC, используя выбор «прочее» на экране источника данных.Таким образом вы получите более высокую производительность и получите больший контроль над соединением через ColdFusion.

Подключение к Oracle информация в ColdFusion Livedocs.

1 голос
/ 21 января 2013

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

установить драйверы ODBC для 64-битной и 32-битной (в этом порядке) на 64-битную ОС win2008

, а затем создать DSN в обеих папках System32и папку SysWow64, запустив файл odbc32ad32.exe

, чтобы убедиться, что ваши tnsnames правильно настроены в соответствующей папке network / admin (если вы используете tnsnames для поддержки своих sids)

теперь на администраторе CF выСоздает новый источник ODBC с aODBC Socket и именем.следующая страница должна показать вам раскрывающийся список всех DSN, которые существуют в настройке 64-битного DSN.Когда вы пойдете и протестируете его в CF, он будет странным образом использовать конфигурацию настройки 32-битного DSN для проверки b

вуаля .... ваши соединения должны работать.Не беспокойтесь об этих архитектурных неудачах и т. Д.

0 голосов
/ 26 августа 2015

Нам нужно было настроить 64-битные соединения ODBC для сервера ColdFusion 11 для запроса к экземпляру SQL Server 2012 на Windows 2008 R2 Server. Соединения ODBC будут обнаружены, но никогда не будут работать. При проверке мы получили так много различных сообщений, как «необходимость работы SSL-соединений», а также сообщения о превышении времени ожидания, так как при входе в SQL Server возникали проблемы.

Я наткнулся на этот пост, и мы решили продолжить настройку 64-битных соединений ODBC и затем перезаписать их - сохранив имя с помощью 32-битного ODBC. Еще раз спасибо товарищам-разработчикам, особенно Souzam! Мои инструкции ниже:


Для Windows 2008R2 Server вы должны замаскировать 64-битные конфигурации сокетов ODBC для 32-битных, чтобы они отображались в CF Admin в качестве источников данных (очевидная ошибка в CF 11):

  1. Создавая 64-битные соединения ODBC через приложение ODBC 2008 R2, следуйте соглашению об именах, которое позволит вам вызывать в 32-битной конфигурации.
  2. Сконфигурируйте 32-битное соединение ODBC в SYSWOW64 (C: \ Windows \ SysWOW64), используя odbcad32.exe, используя предыдущие 64-битные имена в шаге № 1.
  3. Создайте источники данных в CF Admin, так как они должны отображаться в раскрывающемся списке при создании соединений ODBC Socket Type.
...