1、不支持UTF-8
SQL Server有对Unicode的本地支持，使用过nvarchar和ntext字段类型的人都清楚。它通过映射每个字符为双字节实体来内部处理Unicode。如果你 只是处理SQL Server实例之间的数据，那么不会有任何问题，因为它们都以相同 的方式存储。
不过，如果你试图使用BCP从把Unicode导出为UTF-8的数据 来源导入数据，那事情就有点复杂了。UTF-8是Unicode的一种子变体，专门设计 支持与八位ASCII文本的向后兼容，所以默认使用八位ASCII编码的网页、电子邮 件和其它格式可以用于存储Unicode数据。
如果你从UTF-8源导出数据，这些数据就不能使用BCP;它一直不支持UTF-8。你必须考虑数据问题以完整双字节Unicode导出使数据形成可接受格式。具有讽刺意味的是，另一个普通的编码 可以通过“-C”开关（ISO 1252，ANSI/微软公司Windows）被BCP接受。不过，就 整体而言，你最好把数据导出为双字节Unicode，以保持对BCP的最大兼容性，尤 其是如果你处理的数据可能包含与ASCII不兼容的字符。
2、注意导出的行 顺序
使用BCP通过查询导出的数据对于导出顺序遵守相同的规则，会应用 于任何其它情况的查询。换句话说，如果你的查询没有明确的“ORDER BY”从句 ，你获得的数据看起来就是完全任意的顺序。它通常是基于隐含索引中的顺序形 成的，但是我已经学会甚至连经验法则也不相信了——尤其是如果该查询在多个 表之间执行“JOIN”或者一些其它聚合函数。
数据是按什么顺序导出的通 常并不重要，但是数据以什么顺序导入是非常关键的。如果你使用的数据库是后 来导入行的正确性决定于早先存在的行，而且你是批量导入数据的话，那么导出 的顺序就很重要，你需要相应地建立你的BCP语句。这一点似乎显而易见，但是我 经常惊讶有那么多人，甚至包括一些资深的SQL Server专家都没有意识到这一点 。
3、从BCP激活的存储过程不能接收参数
如果你使用带有参数的 存储过程，作为BCP动作Transact-SQL（T-SQL）语句的一部分，几乎可以肯定它 不能用，而且会在命令行抛出函数顺序错误。
当T-SQL语句传递给BCP时， 它将被使用“SET FMTONLY ON”机制进行分析，来判断结果集的柱状格式。这意 味着动态构造语句（比如带参数的存储过程）将不能正确分析，而且也不能在BCP 下编译。
如果你想解决这个问题，有几种方法可以选择：
创建不带任何参数的存储过程，用问号激活存储过程并传入需要的参数（可能 通过数据源而不是命令行接收参数）。
