我有一个平面文件，我使用SSIS将数据导入数据库。当SSIS失败时，它只是报告特定列导入失败。但更确切地说，我想知道平面文件中哪一行发生了错误，以便我可以知道在平面文件中搜索的位置。
示例： 考虑一个平面文件，其中包含以下列名称，年龄，日期。假设该文件有100行。但是如果SSIS在某一行失败，那么在处理列Date时会说80。我收到的错误是，
“组件”派生列“（19）”失败，因为发生错误代码0xC0049063，并且“输出列”DATE“（33）”上的错误行处置指定错误失败。 通过这个我能够理解列日期有一些非数字值。但是如何知道SSIS失败的哪一行（在这种情况下它是Line：88）
我必须知道这一点，因为我有大文件，所以我无法理解解析时错误的来源。
任何人都可以告诉我“Derived Column”（19）中的19是什么，以及“DATE”（33）中的33是“我在错误中得到的。”
答案 0 :(得分：7)
这是我们所做工作的简短描述。首先，我们为包含rowid的所有导入提供了临时表。我们有两个，一个包含原始数据，另一个包含清理数据。然后我们有一个异常表，记录我们正在处理的文件的名称，数据，发送到异常文件的行的rowid，异常的原因以及记录的客户端生成的id（如果有的话） （我们通常需要一个，但对你来说可能不是这样）。您的需求可能因表格中的内容而异。第一个数据流是在执行所有清理步骤后将数据传输到处理表的数据流。
现在，在可能有异常撤出的每个步骤之后，我们将以下内容放在失败路径上（红色箭头副绿色来自任务）），派生列任务以获取我们想要的信息filename和exceptionreason and data然后是到异常表的目标连接以实际插入数据。
最后，我们在数据流之后有一个执行SQl任务，以确定是否有太多异常或异常应该终止整个过程。只有在它通过该步骤后，我们才会执行另一个数据流以插入到prod表中。
现在所有这些复杂性给你带来了什么？首先，如果加载后出现数据问题，您可以轻松查看已清理数据和原始数据之间的差异。这告诉我们发送的数据是否不正确（99％的情况是这种情况，但我们需要向客户证明）或者我们清理它的方式是不正确的。接下来我们确切地知道哪些事情没有通过处理，我们可以轻松地为我们的数据提供者生成他们需要修复的坏数据的列表。最后，我们几乎从不必将负载回滚到prod，因为我们在生产之前完成了所有的修复。并且prod的实际负载更快（我们的prod在与我们的数据处理服务器不同的服务器上），因为它不必在那时执行清理步骤。是的，整体进口可能需要更长时间，但实际上有可能影响我们客户的部分需要更少的时间。
我们还能控制出现失败时的确切行为。在大多数情况下（除了一种特定类型的导入），我们使用失败记录的百分比（与客户达成一致）来确定过程是否失败。这样，百万条记录文件中的4条不良记录将不会停止该过程，但会有100,000条记录。我们有一些东西是showstoppers，甚至一个坏记录是停止这个过程的理由。这使我们可以自由地根据具体情况确定我们想要用来停止该过程的内容。