五餅二魚工作室

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

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

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

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

從上面的結果看起來，似乎不是 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 位址和名稱轉換上的問題了，算是一種避開的方式。

方法二：刪除 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 了。