今天使用SQLCMD導入到SQL SERVER資料庫中,看著數據文件都成功執行，但是意外發現有一個文件數據沒有成功導入，但執行不報錯，很容易導致問題被忽略。 使用存在問題的文件做下測試，從界面上看幾行腳本沒有任何問題： 4條INSERT語句“幾乎”一樣，區別在於最上面三行的部分文字是我從問題語句中粘 ...
今天使用SQLCMD導入到SQL SERVER資料庫中,看著數據文件都成功執行，但是意外發現有一個文件數據沒有成功導入，但執行不報錯，很容易導致問題被忽略。
使用存在問題的文件做下測試，從界面上看幾行腳本沒有任何問題：
4條INSERT語句“幾乎”一樣，區別在於最上面三行的部分文字是我從問題語句中粘貼出來，而最後一行是我手動敲打的。
使用SQLCMD來執行上面4條SQL來執行，執行效果為：
看上去沒有任何錯誤提示，似乎順利執行完成，但數據沒有成功插入到表中，且在沒有設置“SET NOCOUNT ON”的情況下，如果成功插入，應該顯示影響行數。
--=================================================================--
刪除掉手動敲入的命令，將文本變為：
再次執行SQLCMD：
竟然報錯了，顯示字元串亂碼，這可不是執行報錯，而是在語法檢查時便出錯，證明SQL語句存在問題，但任你火眼金睛還是二郎神的三隻眼，這SQL語句真沒問題啊，哪問題出在哪呢？
幸好作為IT狗，經常要編輯上百MB甚至幾個GB的txt文本，習慣使用notepad++這種編輯器，右下角檢查文件類型:
而相對比正常執行的文件，正確的文件類型為：
如果嘗試將上面的文件轉換為GB2312編碼，得到文本為：
跟上面報錯的亂碼文字一比，毫無疑問這就是元凶，隔壁老王家母牛半夜慘叫以及鄰居王小花的內衣丟失案件到此算是告破啦！
--================================================================--
現在很多公司已不局限使用特定資料庫和特定伺服器平臺，Windows +SQL Server使用GBK編碼而Linux+MySQL使用UTF8編碼情況很常見，當兩種資料庫之間導數時很容易發生這種文件類型問題，尤其作為SQL SERVER老鳥，通常我們都會使用SET NOCOUNT ON來提高導入效率，對於這種執行失敗但沒有報出任何錯誤的情況，幾乎都會當初成功執行來對待。
提前祝各位春節快樂！
