Мы переносим базу данных SQL Server 2000 на одном сервере на SQL Server 2008 R2 на другом сервере. Клиентское приложение использует пользовательский DSN для прямого подключения к SQL Server в Интернете.
Я сделал резервную копию базы данных на старом сервере и восстановил ее на новом сервере, и я могу войти в систему с помощью SQL Management Studio, выполнять запросы и т. Д.
SQL Server на новом сервере не является экземпляром по умолчанию, но я использовал SQL Configuration Manager, чтобы изменить порт по умолчанию этого экземпляра на 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, заключается в том, что в старом он является экземпляром по умолчанию, а в новом - это именованный экземпляр.
У тебя есть идеи, что я могу попробовать дальше?
РЕДАКТИРОВАТЬ:
Еще несколько вещей, которые я пробовал:
КОНЕЦ РЕДАКТИРОВАНИЯ
Спасибо!
Луис Алонсо Рамос
Сначала убедитесь, что в вашем экземпляре SQL Server включен протокол TCP / IP. Затем проверьте, какой порт TCP / IP ваш экземпляр SQL Server "прослушивает".
Затем, если на этом компьютере есть брандмауэр, проверьте, есть ли исключение в правилах (входящие) для программы SQL Server Management Studio. Если да, то оно сможет пройти через брандмауэр, а ODBC - нет.
Что касается ссылки на сервер, вы можете попробовать указать свой сервер как «servername \ instancename» или используя номер порта, попробуйте «servername, 1433» или «servername \ instancename, 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 пользователя привязан к одной учетной записи пользователя на машине.
Кажется, что то, чего вы хотите достичь, невозможно с помощью этого клиента.
Проблема возникает из-за того, что старые клиенты SQL (в частности, использующие драйвер MDAC sqlsvr32.dll) выполняют проверку «InstanceValidity» при подключении к SQL Server. Драйвер передает "MSSQLServer" в качестве экземпляра для проверки InstanceValidity. В этом случае, поскольку имя экземпляра, прослушивающего порт по умолчанию (1433), называется «Instance01» и «Instance02», он завершается ошибкой, поскольку имена экземпляров не соответствуют проверке InstanceValidity.
В зависимости от того, что для вас наиболее удобно в этом случае, вам может потребоваться указать порт на вашем клиенте, сменить клиента или изменить именованный экземпляр на экземпляр по умолчанию.
У меня точно такая же проблема, и мне удалось ее решить! Это то, что я узнал.
Если вы установили именованный экземпляр. Вы не можете изменить имя на значение по умолчанию. Однако вы можете: заставить именованный экземпляр прослушивать порт по умолчанию. Что помогает подключиться из Management Studio без указания имени экземпляра, но не помогает для ODBC.
Вы можете создать псевдонимы (с именем, например, MSSQLServer или IP-адресом, в качестве уловки), чтобы ваши клиенты работали. Может работать для некоторых приложений.
Если этот обходной путь не помогает, лучше всего полностью удалить SQL и переустановить его снова, но есть вероятность, что новая установка может снова принять имя указанного экземпляра, даже если вы выбрали «экземпляр по умолчанию». Вы можете проверить это в службах SQL, чтобы увидеть, принимает ли он старое имя. В этом случае лучший способ (который сработал для меня) - установить новый экземпляр с явным именем MSSQLServer, которое, как известно, является именем экземпляра по умолчанию. Это то, что заставит его работать с ODBC.
Отдельно следует отметить: SQL берет имя компьютера и использует его как псевдоним.