SSIS（2008）OLE DB命令中的Randome错误 [英] Randome error in SSIS (2008) OLE DB command

问题描述

大家好，



我来找你帮助理解2008 SSIS包中的一些奇数行为。



在经典的Insert New中 - >更新现有方案（数据库源到数据库目标）SQL 2008 R2，我们得到一些错误记录，错误号如下：

-1071607703 {DTS_E_COMMANDDESTINATIONADAPTERSTATIC_CANTCONVERTVALUE}

varchar（60）列的附加信息点，我们的选择语句实际上是将源值转换为varchar（60）。



面对这样的错误，我们创建了一个带有较大varchar（字段）的双表来存储坏值，以便我们分析它们。好吧，我们什么都没找到;每个记录的长度不超过60个字符，我们甚至能够在原始预期的目标表和坏目标表之间执行UPDATE语句，而不需要单个问题，也无需转换或转换单个值。这种行为一次又一次地重复。这有意义吗？



在将软件包部署到生产环境之前，我们对所有三种情况进行了测试：

a）所有插入

b）一些插入，一些更新

c）所有更新



一旦部署，它在没有问题的情况下运行大约20小时（每10'）之前显示所述行为。



有什么建议吗？



我尝试过：



我们将源DB从生产复制到开发服务器（也是2008 R2），并从SSBIDS以调试模式运行SSIS，没有任何错误。 />


谢谢大家的时间和想法。

Hello everyone,

I come to you for help to understand some odd behavior in a 2008 SSIS package.

In a classical Insert New -> Update Existing scenario (DB Source to DB Destination) both SQL 2008 R2, we are getting a few bad records with the following error number:
-1071607703 {DTS_E_COMMANDDESTINATIONADAPTERSTATIC_CANTCONVERTVALUE}
the additional information points at a varchar(60) column, and our Select statement is in fact Casting the source value to varchar(60).

In face of such error, we created a twin table with a larger varchar(field) to store "bad" values so that we could analyze them. Well, we found nothing; each record had 60 or less characters in length and we were even able to execute an UPDATE statement between the originally intended target table and the "bad" one without a single issue, and without having to cast or convert a single value. This behavior repeated time and time again. Does this make any sense?

Prior deploying the package to production, we did test it for all three scenarios:
a) all insert
b) some insert, some update
c) all update

Once deployed, it ran without issues for about 20hrs (every 10') before showing said behavior.

Any suggestions?

What I have tried:

We copied the source DB from production into a development server (also 2008 R2), and ran the SSIS in debug mode from SSBIDS without a single error.

Thank you all for your time and thoughts.

推荐答案

亲爱的，



鉴于这种情况，我决定保留必要的数据（和SSIS）以供进一步研究。



因此，我做了SSIS的新副本并删除整个转换任务，以便从头开始重建。到目前为止，重建的SSIS的所有测试都已经成功。



感谢大家的想法。我将公布有关此事的任何调查结果。



干杯！

Dear all,

Given the situation, I have decided to keep the necessary data (and SSIS) appart for further study.

Therefore, I made a "new copy" of the SSIS and deleted the entire transformation task in order to rebuild it from scratch. So far, all test runs of the rebuilt SSIS have been successful.

Thank you all for the given thought. I will publish any findings on this matter.

Cheers!

这篇关于SSIS（2008）OLE DB命令中的Randome错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！