我遇到一個奇怪的問題，我嘗試透過 Visual Studio 中的資料來源或透過 SQL 管理控制臺本身連接到在第二台電腦（兩台電腦都執行 Win7 64 位元）上執行的 SQL Server 2008。
第一次嘗試連線時，會逾時。第二次嘗試效果很好。
我可以毫無困難地訪問第二台電腦上的共享，這似乎是我第一次嘗試為每個應用程式實例連接到 SQL。也就是說，如果我開啟兩個 Visual Studio 實例，兩個實例在第一次嘗試連線時都會失敗，但在第二次嘗試連線時會成功。我必須為每個實例連接兩次（無論任何其他應用程式中的失敗/成功順序如何）。
我希望這是有道理的。
有什麼建議嗎？
答案1
我想我找到了解決方案，至少在我的情況下它是有效的。我使用的是實例名稱，這自動意味著 sql server 服務的動態連接埠。我已將設定從動態更改為固定端口，然後打開該端口上的防火牆。
SQL Server 設定管理員 --> SQL Server 網路設定 --> “InstanceName”協定 --> TCP/IP --> 屬性 --> IP 位址 --> IP 全部 -->
在這裡您可以看到兩個選項：
- TCP 動態連接埠：51250（隨機產生）
- TCP 連接埠：空 - 我在這裡輸入 1433，然後打開防火牆（以防尚未開啟）。您可以輸入您想要的任何端口（我輸入 1433 因為它是唯一的實例。如果有多個實例，您應該為每個實例選擇不同的端口，然後在防火牆中打開它們）
該腳本用於簡化您打開我從 MS 下載的連接埠的任務，我在這裡複製它（註釋是德語，但它們應該是顯而易見的）：
@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
答案2
我最好的猜測是你有自動關閉為資料庫開啟。這意味著連線時資料庫需要啟動，這就是初始逾時的原因。
第二個猜測是它可能與主機名稱解析有關。因此，第一次解析主機名稱需要很長時間（也許是透過廣播？），但隨後會在後續連線嘗試時被快取。你用什麼來解析主機？是在 DNS 中嗎？嘗試將連接字串變更為 IP、連接埠格式。即192.168.100.100,1433
您也可以ipconfig /flushdns在成功連線嘗試後嘗試執行，看看是否會得到相同的行為。狡猾的解決方法是將查找放入 HOSTS 檔案中，但您應該正確修復它。
答案3
感覺就像在黑暗中戴著眼罩進行遠距離射擊，但這可能會有所幫助。 Microsoft SQL Developer 論壇上有一個古老的線程，描述了看似相同的問題，以及可能的修復方法。他的伺服器運行的是 Windows Server 2008，但也可能與您的 Win7 設定相關。
線程：
從線程：
是的，我已經解決了這個問題。
我的 Windows Server 2008 配置為拒絕 SASL LDAP 綁定（請參閱警告 2886）。
由於我已將伺服器配置為不拒絕此類綁定，因此 sql server 2008 連線工作正常。
您可以查看 Microsoft KB 935834 以取得有關修改 LDAP 簽章設定的資訊（無法連結到它，因為我是新使用者）。
希望能幫助你！
答案4
您能否在首次使用 VS 或 SSMS 連線之前嘗試執行 SQL Profiler，並查看 SQL Server 上發生了什麼？
另外，您是否檢查過事件日誌以查看是否記錄了任何內容？