Как подключить ODBC DSN к экземпляру SQL Server, не установленному по умолчанию, на порту по умолчанию?

Мы переносим базу данных SQL Server 2000 на одном сервере в SQL Server 2008 R2 на другом сервере. Клиентское приложение использует DSN пользователя для прямого подключения к серверу SQL в Интернете.

Я создал резервную копию базы данных на старом сервере и восстановлен на новом сервере, и я могу войти в систему с помощью SQL Management Studio, выполнить запросы и т. Д.

SQL Server на новом сервере не является экземпляром по умолчанию, но я использовал диспетчер конфигурации SQL, чтобы изменить порт по умолчанию для этого экземпляра на 1433. SQL Management Studio может подключиться к правильному экземпляру, просто указав IP-адрес сервера или имя домена (поэтому нет проблем с брандмауэром, или я так думаю).

Все идет нормально.

Проблема возникает, когда я пытаюсь подключиться к серверу с помощью моего клиентского приложения. Я получаю сообщение об ошибке подключения / недопустимый экземпляр. Клиентское приложение работает примерно на 100 компьютерах в 50 разных местах, поэтому перенастройка каждого из них не может быть выполнена за один день, что может привести к простоям.

Я попытался создать DSN на своем компьютере, чтобы проверить соединение. Если я указываю IP-адрес с номером порта (123.123.123.123,1433), он работает, но если я использую только IP-адрес (123.123.123.123), я получаю ту же ошибку, что и выше.


Ошибка подключения:
SQLState: '01000'
Ошибка SQL Server: 14
[Microsoft][Драйвер ODBC SQL Server][Сокеты TCP/IP]ConnectionOpen (недопустимый экземпляр ()).
Ошибка подключения:
SQLState: '08001'
Ошибка SQL Server: 14
[Microsoft][Драйвер ODBC SQL Server][Сокеты TCP/IP] Неверное соединение.


Единственное различие, которое я могу представить между новым сервером и старым, кроме версии SQL Server, заключается в том, что на старом это экземпляр по умолчанию, а на новом - именованный экземпляр.

У вас есть идеи, что я мог бы попробовать дальше?

РЕДАКТИРОВАТЬ:

Несколько других вещей, которые я пробовал:

  • Я использую драйвер ODBC для SQL Server. Если я использую драйвер собственного клиента SQL Server, все работает, как я ожидаю.
  • Если я создаю соединение DSN на том же сервере, используя общедоступный IP-адрес сервера, наблюдается то же поведение.
  • Если я остановлю экземпляр не по умолчанию и запусту экземпляр по умолчанию на порту 1433, он будет работать как положено (без указания порта). Если я настраиваю экземпляр по умолчанию для прослушивания порта 1433, мне нужно явно указать порт для подключения.

КОНЕЦ РЕДАКТИРОВАНИЯ

Спасибо!

Луис Алонсо Рамос

3 ответа

Решение

Кажется, что то, чего вы хотите достичь, невозможно с помощью этого клиента.

Проблема связана с тем, что старые клиенты SQL (в частности, с помощью драйвера MDAC sqlsvr32.dll) выполняют проверку "InstanceValidity" при подключении к SQL Server. Драйвер передает "MSSQLServer" в качестве экземпляра для проверки на проверку InstanceValidity. В этом случае, поскольку имя экземпляра, прослушивающее порт по умолчанию (1433), называется "Instance01" и "Instance02", происходит сбой, поскольку имена экземпляров не соответствуют проверке InstanceValidity.

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

Источник: http://social.msdn.microsoft.com/Forums/sqlserver/en-US/7f353b59-7e7f-4ec3-adcb-e69ca2629b21/named-sql-2008-r2-server-listening-on-default-port-1433-with-dedicated-ip-address-requires-port?forum=sqldataaccess

Сначала убедитесь, что на вашем экземпляре SQL Server включен протокол TCP/IP. Затем проверьте, какой порт TCP/IP "слушает" ваш экземпляр SQL Server.

Тогда Если на этом компьютере установлен брандмауэр, проверьте, не существует ли исключение в правилах (входящих) для программы SQL Server Management Studio. Если это так, то он сможет проходить через брандмауэр, а ODBC - нет.

Что касается ссылки на сервер, вы можете попробовать указать ссылку на свой сервер как "имя_сервера \ имя_экземпляра" или, используя номер порта, указать "имя_сервера \ 1433" или "имя_сервера \ имя_экземпляра, 1433" в качестве адреса своего сервера.

Вашему серверу также необходимо знать, на какой порт отвечать, когда порт TCP пуст, это не значит, что используется порт по умолчанию. В зависимости от того, чего вы хотите достичь, вам может потребоваться выполнить или проверить, правильно ли выполнено одно из следующих действий:

Как происходит распределение портов на вашем сервере https://dba.stackexchange.com/questions/47651/when-is-a-dynamic-port-dynamic

Настройка сервера для прослушивания определенного порта TCP (диспетчер конфигурации SQL Server) http://msdn.microsoft.com/en-us/library/ms177440.aspx

Назначьте статический порт для именованного экземпляра SQL Server и избегайте распространенных ошибок http://blogs.msdn.com/b/arvindsh/archive/2012/09/08/how-to-assign-a-static-port-to-a-sql-server-named-instance-and-avoid-a-common-pitfall.aspx

Для подключения к удаленным серверам SQL у вас есть два варианта: использовать IP и порт (что безопаснее) или явно указать именованный экземпляр, открыть порт UDP 1434 и включить браузер SQL Server.

Причина в том, что только именованные экземпляры SQL Server могут использовать процесс динамического выделения портов. В процессе динамического выделения портов при первом запуске экземпляра SQL Server порт устанавливается в ноль (0). Поэтому SQL Server запрашивает свободный номер порта у операционной системы. Как только номер порта выделен для SQL Server, SQL Server начинает прослушивать выделенный порт.

Когда экземпляр SQL Server использует динамическое распределение портов, строка подключения, созданная на клиенте SQL Server, не указывает целевой порт TCP/IP, если только пользователь или программист явно не указывает порт. Поэтому клиентская библиотека SQL Server запрашивает сервер на UDP-порту 1434 для сбора информации о целевом экземпляре SQL Server. Когда SQL Server возвращает информацию, клиентская библиотека SQL Server отправляет данные в соответствующий экземпляр SQL Server.

Если UDP-порт 1434 отключен, клиент SQL Server не может динамически определить порт именованного экземпляра SQL Server. Следовательно, клиент SQL Server может не подключиться к именованному экземпляру SQL Server. В этой ситуации клиент SQL Server должен указать динамически назначенный порт, на котором находится именованный экземпляр SQL Server 2008.

Кроме того, в зависимости от того, что вы хотите, вы можете использовать системный ODBC, а не пользовательский ODBC. Разница в том, что ODBC пользователя привязан к одной учетной записи пользователя на машине.

У меня точно такая же проблема, и мне удалось ее решить! Это то, что я узнал.

  • Если вы установили именованный экземпляр. Вы не можете изменить имя по умолчанию. Однако вы можете: заставить именованный экземпляр слушать порт по умолчанию. Который помогает подключиться из Management Studio без указания имени экземпляра, но не помогает для ODBC.

  • Вы можете создать псевдонимы (с таким именем, как MSSQLServer или IP-адрес, как трюк), чтобы заставить ваших клиентов работать. Может работать для некоторых приложений.

  • Если этот обходной путь не помогает, то лучше всего полностью удалить SQL и заново установить его, но есть вероятность, что новая установка может снова взять имя именованного экземпляра, даже если вы выбрали "экземпляр по умолчанию". Вы можете проверить это в службах SQL, чтобы убедиться, что оно все еще принимает старое имя. В этом случае лучший способ (который работал для меня) - установить новый экземпляр с явным именем MSSQLServer, который известен как имя экземпляра по умолчанию. Это то, что заставит его работать с ODBC.

Отдельное примечание: SQL берет имя компьютера и использует его в качестве псевдонима.

Другие вопросы по тегам