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下编译。
如果你想解决这个问题，有几种方法可以选择：
创建不带任何参数的存储过程，用问号激活存储过程并传入需要的参数（可能通过数据源而不是命令行接收参数）。
用sqlcmd替代BCP。
MSDN博客中提到了一个处理技巧，需要使用称为“openrowset”的技巧。如果你通过“OPENROWSET ”函数运行“SELECT”，你可以以临时方式传递一个T-SQL语句，从而解决调用带参数存储过程的限制。然而，这种处理技巧也有局限：例如，与语句连 接时不应该使用，因为运行会对数据库造成消极变化，而且该语句可能需要运行不止一次。
4、导入时要注意表定义
当你使用BCP从一个SQL Server源导出数据，并导入到另一个SQL Server时，你导出时的列定义和导入时的列定义必须相匹配。这也包括诸如NULL或者NOT NULL这类定义，在目标表缺少它们会引起静默数据损坏。
5、在目标数据库上的触发器不能被BCP触发
不管什么时候运行导入操作，BCP的本地行为在目标数据库上都会禁用触发器。因为BCP导入操作通常很大，如果按默认启用触发器的话，导入操作会很混乱。因此，你需要在BCP上使用命令选项“-h FIRE_TRIGGERS”，这样触发器才会被触发。
要注意，当选项启用时，触发器会为每个批量操作运行一次，——也就是说，每次你运行BCP时执行一次。另外还要注意，在SQL Server 2005和以后的版本中，触发器使用了“行版本”，在导入操作时用tempdb来存储行版本信息。如果你的tempdb不能容纳触发器生成的大量数据涌 入，该操作将异常终止。
6、BCP不能给本地附加文件输出
如果你使用BCP导出数据到文件，该文件必须是新创建的。你不能选择现存文件，并把导出结果追加到文件。幸运的是，解决办法并不困难，您可以简单地导出到任何多个文件，然后使用COPY命令来整合这些结果。命令如下：
COPY export1.dat + export2.dat export.dat
====================================分割线================================
最新内容请见作者的GitHub页：http://qaseven.github.io/
