Estou tendo um problema estranho ao tentar conectar-me ao SQL Server 2008 em execução em um segundo computador (ambas as máquinas executando Win7 de 64 bits), por meio das fontes de dados no Visual Studio ou pelo próprio console de gerenciamento SQL.
Na primeira tentativa de conexão, o tempo limite. A segunda tentativa funciona bem.
Posso acessar compartilhamentos no segundo computador sem nenhuma dificuldade, apenas parece ser a primeira vez que tento me conectar ao SQL para cada instância do aplicativo. Ou seja, se eu abrir duas instâncias do Visual Studio, ambas falharão na primeira tentativa de conexão, mas serão bem-sucedidas na segunda. Tenho que me conectar duas vezes para cada instância (independentemente da sequência de falha/sucesso em qualquer outro aplicativo).
Espero que faça sentido.
Algum conselho?
Responder1
Acho que encontrei a solução, pelo menos no meu caso está funcionando. Estou usando o nome da instância e isso implica automaticamente uma porta dinâmica para o serviço do SQL Server. Alterei as configurações de dinâmica para uma porta fixa e abri o firewall nessa porta.
Gerenciador de configuração do SQL Server -> Configuração de rede do SQL Server -> Protocolos para 'InstanceName' -> TCP/IP -> Propriedades -> Endereços IP -> IP Todos ->
Aqui você vê duas opções:
- Portas dinâmicas TCP: 51250 (geradas aleatoriamente)
- Porta TCP: vazia - coloquei aqui 1433 e depois abri o firewall (caso ainda não estivesse aberto). Você pode colocar a porta que quiser (coloquei 1433 porque era a única instância. No caso de múltiplas instâncias você deve escolher para cada instância uma porta diferente e depois abri-las no firewall)
O script facilitou sua tarefa de abrir as portas que baixei do MS e estou reproduzindo aqui (os comentários estão em alemão, mas devem ser óbvios):
@echo ========= Ports des SQL-Servers ===================
@echo Aktivieren von Port 1433 für die SQLServer-Standardinstanz
netsh firewall set portopening TCP 1433 "SQLServer"
@echo Aktivieren von Port 1434 für dedizierte Administratorverbindungen
netsh firewall set portopening TCP 1434 "SQL-Administratorverbindung"
@echo Aktivieren von Port 4022 für den konventionellen SQL Server-Service Broker
netsh firewall set portopening TCP 4022 "SQL-Service Broker"
@echo Aktivieren von Port 135 für Transact-SQL-Debugger/RPC
netsh firewall set portopening TCP 135 "SQL-Debugger/RPC"
@echo ========= Ports für Analysedienste ==============
@echo Aktivieren von Port 2383 für die SSAS-Standardinstanz
netsh firewall set portopening TCP 2383 "Analysedienste"
@echo Aktivieren von Port 2382 für den SQL Server-Browserdienst
netsh firewall set portopening TCP 2382 "SQL-Browser"
@echo ========= Verschiedene Anwendungen ==============
@echo Aktivieren von Port 80 für HTTP
netsh firewall set portopening TCP 80 "HTTP"
@echo Aktivieren von Port 443 für SSL
netsh firewall set portopening TCP 443 "SSL"
@echo Aktivieren des Ports für die Schaltfläche 'Durchsuchen' des SQL Server-Browserdiensts
netsh firewall set portopening UDP 1434 "SQL-Browser"
@echo Zulassen von Multicast-/Broadcastantwort auf UDP (Aufzählung der Browserdienste OK)
netsh firewall set multicastbroadcastresponse ENABLE
Responder2
Meu melhor palpite aqui é que você temAUTO_CLOSEativado para o banco de dados. Isso significa que o banco de dados precisa ser ativado quando você se conecta, o que está causando o tempo limite inicial.
O segundo palpite é que pode estar relacionado à resolução do nome do host. Portanto, demora muito para resolver o nome do host na primeira vez (talvez por transmissão?), mas depois é armazenado em cache nas tentativas de conexão subsequentes. O que você está usando para resolver o host? está no DNS? Tente alterar a cadeia de conexão para um formato de porta IP. ou seja, 192.168.100.100.1433
Você também pode tentar executar ipconfig /flushdnsapós uma tentativa de conexão bem-sucedida e ver se obtém o mesmo comportamento. A solução duvidosa é colocar a pesquisa em seu arquivo HOSTS, mas você deve corrigi-la corretamente.
Responder3
Parece um tiro no escuro com uma venda nos olhos, mas pode ajudar. Há um tópico antigo nos fóruns do Microsoft SQL Developer que descreve o que parece ser o mesmo problema, junto com uma possível correção. O servidor dele está executando o Windows Server 2008, mas também pode ser relevante para a configuração do Win7.
O segmento:
Do tópico:
Sim, resolvi esse problema.
Meu servidor Windows 2008 foi configurado para rejeitar ligações SASL LDAP (consulte o aviso 2886).
Como configurei meu servidor para não rejeitar essas ligações, as conexões do SQL Server 2008 funcionam corretamente.
Você pode consultar o Microsoft KB 935834 para obter informações sobre como modificar as configurações de assinatura LDAP (não é possível vincular a ele porque sou um novo usuário).
Espero que ajude!
Responder4
Você pode tentar executar o SQL Profiler antes de se conectar pela primeira vez ao VS ou ao SSMS e ver o que está acontecendo no SQL Server?
Além disso, você verificou os logs de eventos para ver se algo está sendo registrado?