Como conectar um ODBC DSN à instância não padrão do SQL Server na porta padrão?

Question

Estamos migrando um banco de dados do SQL Server 2000 em um servidor para o SQL Server 2008 R2 em outro servidor. O aplicativo cliente usa um DSN de usuário para se conectar diretamente ao SQL Server na Internet.

Eu fiz backup do banco de dados no servidor antigo e o restaurei no novo servidor, e posso fazer login usando o SQL Management Studio, executar consultas e assim por diante.

O SQL Server no novo servidor não é a instância padrão, mas usei o SQL Configuration Manager para alterar a porta padrão dessa instância para 1433. O SQL Management Studio pode se conectar à instância correta apenas especificando o IP ou domínio do servidor nome (assim não há problemas de firewall, ou assim eu acho).

Até agora, tudo bem.

O problema ocorre quando tento conectar-me ao servidor com o aplicativo cliente. Eu recebo um erro de conexão / erro de instância inválido. O aplicativo cliente é executado em cerca de 100 computadores em 50 locais diferentes, portanto, a reconfiguração de cada um não pode ser feita em um dia, causando assim algum tempo de inatividade.

Eu tentei criar um DSN no meu computador para testar a conexão. Se eu especificar o endereço IP com um número de porta (123.123.123.123,1433) ele funciona, mas se eu usar apenas o endereço IP (123.123.123.123), recebo o mesmo erro acima.

Falha na conexão:
SQLState: '01000'
Erro do SQL Server: 14
[Microsoft] [Driver ODBC do SQL Server] [Sockets TCP / IP] ConnectionOpen (Invalid Instance ()).
Falha na conexão:
SQLState: '08001'
Erro do SQL Server: 14
[Microsoft] [Driver ODBC do SQL Server] [Sockets TCP / IP] Conexão inválida.

A única diferença que posso imaginar entre o novo servidor e o antigo, além da versão do SQL Server, é que no antigo é a instância padrão, enquanto no novo é uma instância nomeada.

Você tem alguma ideia do que eu poderia tentar em seguida?

EDITAR:

Algumas outras coisas que tentei:

• Estou usando o driver ODBC do SQL Server. Se eu usar o driver do SQL Server Native Client, tudo funcionará como esperado.
• Se eu criar a conexão DSN no mesmo servidor, usando o endereço IP público do servidor, o mesmo comportamento será observado.
• Se eu parar a instância não padrão e executar a instância padrão na porta 1433, ela funcionará conforme o esperado (sem especificar a porta). Se eu definir a instância não padrão para escutar na porta 1433, preciso especificar explicitamente a porta a ser conectada.

END EDIT

Obrigado!

Luis Alonso Ramos

    

Answer 1

Parece que o que você deseja alcançar não é possível usando esse cliente.

O problema é o resultado de clientes SQL mais antigos (especificamente usando o driver sqlsvr32.dll do MDAC) executar uma verificação de "InstanceValidity" ao conectar-se ao SQL Server. O driver passa "MSSQLServer" como a instância para verificar a verificação InstanceValidity. Nesse caso, como o nome da instância que atende na porta padrão (1433) é denominado "Instance01" e "Instance02", ele falha porque os nomes da instância não correspondem à verificação InstanceValidity.

De acordo com o que é mais conveniente para você nesse caso, pode ser necessário especificar a porta em seu cliente, alterar seu cliente ou alterar sua instância nomeada para ser sua instância padrão.

Fonte: link

    

Answer 2

Primeiro, verifique se sua instância do SQL Server tem o protocolo TCP / IP ativado. Em seguida, examine qual porta TCP / IP sua instância do SQL Server está "escutando".

Em seguida, se houver um firewall nessa máquina, marque Se houver uma exceção nas regras (entrada) para o programa SQL Server Management Studio Em caso afirmativo, ele poderá passar pelo firewall, mas o ODBC não.

Sobre a referência do servidor, você pode tentar Referenciar seu servidor como "servername \ instancename" ou usar o número da porta, tente "servername, 1433" ou "servername \ instancename, 1433" como seu endereço de servidor.

O seu servidor também precisa saber em qual porta responder, quando a porta TCP estiver em branco, não significa usar a porta padrão. Dependendo do que você deseja alcançar, pode ser necessário fazer ou verificar se uma dessas ações é feita corretamente:

Como a alocação de portas é definida no seu servidor link

Configurar um servidor para escutar em uma porta TCP específica (SQL Server Configuration Manager) link

Atribuir uma porta estática a uma instância nomeada do SQL Server - e evitar uma armadilha comum link

Para conectar-se a servidores SQL remotos, você tem duas opções: uma é usar IP e Port (que é mais seguro) ou explícita especificar a instância nomeada e abrir a porta UDP 1434 e habilitar o navegador do SQL Server.

O motivo é: Somente instâncias nomeadas do SQL Server podem usar o processo de alocação de porta dinâmica. No processo de alocação de porta dinâmica, quando você inicia a instância do SQL Server pela primeira vez, a porta é definida como zero (0). Portanto, o SQL Server solicita um número de porta livre do sistema operacional. Assim que um número de porta é alocado para o SQL Server, o SQL Server inicia a escuta na porta alocada.

Quando uma instância do SQL Server usa alocação de porta dinâmica, a cadeia de conexão criada no cliente do SQL Server não especifica a porta TCP / IP de destino, a menos que o usuário ou o programador especifique explicitamente a porta. Portanto, a biblioteca de cliente do SQL Server consulta o servidor na porta UDP 1434 para coletar as informações sobre a instância de destino do SQL Server. Quando o SQL Server retorna as informações, a biblioteca cliente do SQL Server envia os dados para a instância apropriada do SQL Server.

Se a porta UDP 1434 estiver desabilitada, o cliente do SQL Server não poderá determinar dinamicamente a porta da instância nomeada do SQL Server. Portanto, o cliente do SQL Server talvez não consiga se conectar à instância nomeada do SQL Server. Nessa situação, o cliente do SQL Server deve especificar a porta alocada dinamicamente onde a instância nomeada do SQL Server 2008.

Além disso, dependendo do que você deseja, você pode querer usar um ODBC do sistema, em vez de um ODBC do usuário. A diferença é que o ODBC do usuário está vinculado a uma conta de usuário na máquina.

    

Answer 3

Eu tenho exatamente o mesmo problema e consegui resolvê-lo! Isso é o que eu aprendi.

• Se você instalou uma instância nomeada. Você não pode alterar o nome para o padrão. Você pode, no entanto: fazer a instância nomeada ouvir a porta padrão. Que ajudam a se conectar a partir do Management Studio sem especificar um nome de instância, mas não ajuda no ODBC.

• Você pode criar aliases (com nome como MSSQLServer ou o endereço IP, como um truque) para fazer seus clientes funcionarem. Pode funcionar para algumas aplicações.

• Se essa solução alternativa não ajudar, sua melhor opção será desinstalar completamente o SQL e reinstalá-lo novamente, mas a nova instalação pode levar o nome da instância nomeada novamente, mesmo que você tenha selecionado 'instância padrão'. Você pode verificar isso nos serviços SQL para ver se ainda está usando o nome antigo. Nesse caso, a melhor maneira (que funcionou para mim) é instalar uma nova instância com o nome explícito do MSSQLServer, que é conhecido como o nome da instância padrão. Isto é o que fará com que funcione com o ODBC.

Em uma nota separada: o SQL pega o nome do computador e o usa como um alias.