Почему SQL Server 2008 OLE DB UDL может требовать явного указания порта 1433?


В рабочей среде я обнаружил, что порт 1433 должен быть явно указан для UDL "Microsft OLE DB Provider for SQL Server". Вот так:

Provider=SQLOLEDB.1;User ID=USER;Data Source=IP,1433

Без указанного порта ошибка выглядит следующим образом:

 Test connection failed because of an error in initializing provider.
 [DBNETLIB][ConnectionOpen (Invalid Instance()).]Invalid connection.

Та же среда, но SQL Native Client 10.1, не требует явного указания 1433:

Provider=SQLNCLI10.1;Integrated Security="";Persist Security Info=False;
User ID=USER;Data Source=IP;...

Тот же тест для SQL-сервера разработки, OLE DB UDL не требует указанного порта по умолчанию.

При каких обстоятельствах это может произойти? необходимо ли явно указать порт по умолчанию?

Производственная система является кластеризованной, с первичным активным и вторичным пассивным сервером и кластерным сервером, к которому выполняются соединения. Среда разработки - это всего лишь один SQL Server 2008. Я не знаю никаких других различий. Если вы думаете, что это играет свою роль, почему это может иметь значение?

Клиент для SQL Server (где был создан UDL): Стандарт Windows Server 2008 R2 MDAC 2.8

Вся база данных SQL Сервера: Microsoft SQL Server 2008 (SP1) - 10.0.2734.0 (X64) Пакет Обновления 2 Для Windows Server Enterprise

Заранее спасибо за любую помощь.

2 4

2 ответа:

Это известная проблема, которая уникальна для кластеризации. Причина в том, что менеджер кластера будет отвечать на один IP / порт, а затем передавать сообщения на фактический(физический) сервер, который может взаимодействовать с другим портом. Похоже, что исправления не будет, но вы уже нашли обходной путь.
Дополнительные сведения см. В статье Microsoft Technet: http://support.microsoft.com/kb/318432

Мне приходилось делать это несколько раз. Две основные причины являются

1) Брандмауэр - Убедитесь, что порт 2382 открыт для службы SQL Browser и разрешает внешние подключения. Дополнительные сведения: порты брандмауэра sql server

2) существующий псевдоним SQL-Откройте "Диспетчер конфигурации Sql Server". Разверните раздел" Конфигурация собственного клиента SQL 10.0", псевдонимы. Если они есть в списке, проверьте, установлен ли порт. Иногда эти записи устанавливаются при работе с ODBC параметры сервера. Затем они застревают, и кажется, что их можно удалить/исправить только с помощью диспетчера конфигурации SQL.