alexvw Ответов: 1

Ошибка Randome в команде SSIS (2008) OLE DB


Всем привет,

Я пришел к вам за помощью, чтобы понять некоторые странный поведение в пакете служб SSIS 2008 года.

В классическом сценарии Insert New- & gt; Update Existing scenario (DB Source to DB Destination) как SQL 2008 R2, мы получаем несколько плохих записей со следующим номером ошибки:
-1071607703 {DTS_E_COMMANDDESTINATIONADAPTERSTATIC_CANTCONVERTVALUE}
дополнительная информация указывает на колонку varchar (60), а наша Выбрать оператор фактически приводит исходное значение к varchar(60).

Перед лицом такой ошибки мы создали двойную таблицу с большим varchar (полем) для хранения "плохих" значений, чтобы мы могли их анализировать. Что ж, мы ничего не нашли каждая запись имела длину 60 или менее символов, и мы даже смогли выполнить оператор UPDATE между первоначально предназначенной целевой таблицей и "плохой" таблицей без единой проблемы и без необходимости приведения или преобразования одного значения. Такое поведение повторялось снова и снова. Есть ли в этом какой-то смысл?

Перед развертыванием пакета в производство мы протестировали его для всех трех сценариев:
а) все вставки
б) некоторые вставки, некоторые обновления
в) все обновления

После развертывания он работал без проблем около 20 часов (каждые 10'), прежде чем показать указанное поведение.

Есть предложения?

Что я уже пробовал:

Мы скопировали исходную базу данных из рабочей среды на сервер разработки (также 2008 R2) и запустили SSIS в режиме отладки из SSBIDS без единой ошибки.

Спасибо всем вам за ваше время и мысли.

Richard MacCutchan

Вы не упомянули, на какую ценность он жалуется.

alexvw

Доброе утро, Ричард, это не шутка.
конкретное значение; он придумал различные записи (не обязательно одни и те же). Во всяком случае, это простые струны. Источник-это:

Выберите Cast (Trim(field01) as varchar(60)) as InputValue
От dbo.sourcetable

Поле таблицы назначения объявляется как varchar(60).

Все значения вставляются без проблем, но описанная ошибка ramdomly появляется во время обновлений и только в рабочей среде. Кстати, он даже появляется при попытке обновить вставленную запись своими собственными значениями.

Как ни странно, те же самые данные и службы SSIS не вызывают инцидентов при работе в среде разработки.

Извините, я не могу быть более конкретным; о! Я могу сказать, что эти строки не имеют тревожных символов, таких как:',",--,; и т. д.)

Во всяком случае, спасибо, что заглянули. Я прослежу, чтобы поделиться какой-либо выводов с моей стороны.

Richard MacCutchan

Да, но что такое field01 и зачем вам нужен гипс?

alexvw

Источником является поле char (100), которое содержит различные значения длины не более 50 символов.

Было решено сбросить их в колонну varchar (60 в длину), таким образом оставляя место для непредвиденных больших значений. Отсюда и актерский состав.

1 Ответов

Рейтинг:
11

alexvw

Дорогие все,

Учитывая сложившуюся ситуацию, я решил сохранить необходимые данные (и SSIS) для дальнейшего изучения.

Поэтому я сделал "новую копию" SSIS и удалил всю задачу преобразования, чтобы перестроить ее с нуля. До сих пор все тестовые запуски перестроенных SSIS были успешными.

Спасибо вам всем за данную мысль. Я опубликую любые выводы по этому вопросу.

Ура!