TLDR 版本：批量插入将告诉您它影响了多少行。它不会告诉你它试图影响多少行，或者有多少行失败。这个问题很明显，我想知道是否有更可靠的方式从文本文件上传，将代码保存在服务器中。
完整版：我有一个应用程序需要定期将文本数据文件上传到 SQL Server 表中。出于某种疯狂和疯狂的原因，我想把它放在一个存储过程中，使其成为抽象层的一部分，而不是让前端应用程序直接写入表。
与大多数 SQL Server 脚本一样，我通常会花费大量时间将头撞在砖墙上以使其完全正常工作。（通过搜索本网站和其他网站上的过去帖子获得了不小的帮助。）
批量插入是否会读取标题行以确定要写入哪些字段？不，我必须使用格式文件（并希望表结构/顺序永远不会改变）或使用仅包含数据文件中的列的临时表。暂存表在将数据复制到实际表之前接收数据。
如果您省略了目标表中的单个列（即使是具有默认值的列）并且不使用格式文件怎么办？您会收到不言自明的错误消息“无法从链接服务器“（null）”的 OLE DB 提供程序“BULK”中获取一行。” 使用上述临时表，省略任何不在数据源中的列，可以解决这个问题。
没关系，我可以忍受。这不是可怕的部分。这是。
如果暂存表仍有任何定义为 NOT NULL 的字段，但该列的数据源行为 null，则不会出现错误。根据我的测试，如果您有（比如说）5 行数据并且第 3 行在 NOT NULL 字段中缺少数据，那么您不会收到错误消息，但会收到“4 行已更新”消息。如果您期望 5 行并交叉检查受影响的行数以确保存在预期的行数，这一切都很好，但这些文件的长度会有所不同，批量插入不会告诉您它实际读取了多少行。更糟糕的是，在某些情况下，一行中缺少的字段也会阻止下一个（有效）行的上传。
明显的解决方案？从暂存表中删除 NOT NULL 约束并处理暂存表和真实表之间的接口中的任何空异常。但是...我担心的是，在我还没有遇到的其他情况下，这段 cro...ode 可能会做同样的事情。也就是说，读取一行，未能将其写入暂存表，并且不抛出异常，因此没有人知道数据丢失，直到他们去寻找它并发现它不存在。甚至 Access 也有比这更好的文本导入选项。
那么，我的问题是......是否有更好（更可靠）的方式来处理将可变行长度文本文件上传到 SQL Server 而不必依赖前端应用程序来完成它？
提前感谢您的任何建议。