今天使用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来提高导入效率，对于这种执行失败但没有报出任何错误的情况，几乎都会当初成功执行来对待。
提前祝各位春节快乐！
补上妹子
