[SQL][Troubleshooting]無法使用 127.0.0.1 連接本機 SQL Server ?

[SQL][Troubleshooting]無法使用 127.0.0.1 連接本機 SQL Server ?

上個月寫了一篇有關於 「SQL Server 連線問題」的文章,這幾天就遇到有朋友發生無法連接本機 SQL Server 的問題,他也有按照之前所介紹的方法,但還是無法成功連線,於是透過連線軟體幫忙看一下問題。

 

看到這樣的錯誤訊息,當下覺得有點納悶,會不會是權限不夠還是帳號被拒絕呢 ?

image

 

於是更改了連線主機的設定,不論使用「(local)」、「localhost」、「JamesPC」(電腦名稱)、「192.168.10.1」(IP 位址 ) 這幾種方式都可以,唯有 127.0.0.1 不行 ?! 這實在太奇怪了,照理說如果是 TCP 是無法使用的,不會只有 127.0.0.1 是不行的,用實際 IP 反而是可以的狀況。

image

 

於是當下想說會不會是 SSMS 的問題,於是決定開 OSQL 來測試

image

 

從上面的結果看起來,似乎不是 SSMS 的問題,看起來是在解析 127.0.0.1 的時候出了一些問題,才導致 SQL Server 的誤判。既然知道問題可能會是這樣,但會是誰造成的呢 ? 相信很多人看到這裡差不多就已經會有答案了,因為在 Windows 環境下要解析名稱轉換,除了透過 DNS 外,還會去參考 Hosts ( 在 Windows\System32\drivers\ets 的目錄下 )。而 127.0.0.1 應該跟 DNS 比較沒有關係,所以我們決定來查看看 Hosts 裡面有沒有甚麼問題。

# localhost name resolution is handled within DNS itself.
#    127.0.0.1       localhost
#    ::1             localhost
127.0.0.1            sqlserver

 

果不其然,原來在 Hosts 裡面多了一組設定。找了一下相關人員詢問,可能是安裝了某個產品,他們為了方便指定連接的 SQL Server,因此在程式中都固定連接 sqlserver 這個名稱,然後再來調整 Hosts 了。的確這個是一個方式,但是造成我們直接在本機電腦連接 SQL Server,又剛好採用 Windows 認證方式登入的時候,可能這當中有 IP & 電腦名稱轉換上造成了混淆,才導致在電腦上無法用主機名稱是 127.0.0.1 ,且採用 Windows 認證連接 SQL Server。

 

那知道問題了要如何來解決呢 ? 於是提供兩種方式讓使用者自己去決定該如何處理;

 

方法一:要是保持 Hosts 內的設定的話,那麼再開啟 SSMS 的時候,設定 127.0.0.1 連接 SQL Server 的時候採用 「Named Pipes」,只要設定一次讓 SSMS 記錄起來就可以了。因為這樣就不會有 TCP/IP 位址和名稱轉換上的問題了,算是一種避開的方式。

image

 

方法二:刪除 Hosts 檔案內的 127.0.0.1 的設定,到伺服器管理員內的 「SQL Native Client 11.0 組態」→「別名」內去新增一組別名是 sqlserver,讓這個別名設定是走 TCP/IP 連接 127.0.0.1 到本機的 SQL Server。這樣原本程式內的也不用修改,而也恢復可以正常使用 127.0.0.1 連接本機的 SQL Server 了。

image