У меня есть база данных SQL Server 2005 с пакетом обновления 2 (SP2), которая имеет таблицу с атрибутом poc_resp_city, которая равна nvarchar(35).Ошибка обрезки строки SSIS
Было изменено на nvarchar(80) 2 месяца назад, не выравнивая тот же атрибут в хранилище данных. (Который до сих пор nvarchar(35))
Загрузочные данных пакета служб SSIS (после двух месяцев правильной работы) теперь дает обратный сбой пакета каждый раз, когда я запускаю его со следующей ошибкой:
There was an error with output column "poc_resp_city" (2250) on output "OLE DB Source Output" (11). The column status returned was: "Text was truncated or one or more characters had no match in the target code page.". There was an error with output column "poc_resp_city" (2250) on output "OLE DB Source Output" (11). The column status returned was: "Text was truncated or one or more characters had no match in the target code page.".
SSIS Error Code DTS_E_PRIMEOUTPUTFAILED. The PrimeOutput method on component "Source Table" (1) returned error code 0xC020902A. The component returned a failure code when the pipeline engine called PrimeOutput(). The meaning of the failure code is defined by the component, but the error is fatal and the pipeline stopped executing. There may be error messages posted before this with more information about the failure.
Ни пакет, ни в базы данных были изменены по этой проблеме. Я знаю, что я мог проигнорировать эту ошибку, или я мог бы договориться о том, чтобы она работала, но я хочу предоставить правильный и приемлемый ответ, почему эта ошибка появляется через 2 месяца после изменения? Потому что, может быть, я пропустил важный шаг в этой ситуации.
Важное примечание. У меня нет даже одной записи, которая имеет более 35 символов, поэтому усечение никогда не происходит. (это предупреждение относится к какому-то шагу проверки SSIS)
Теперь я думаю, что, возможно, через некоторое время пакет SSIS перекомпилирует себя, и теперь он видит это несоосность в своих метаданных (35 =/= 80), и потому Атрибут TruncationRowDisposition установлен в RD_FailComponent, он не выполняет компонент.
И я бы исключил вариант кодовой страницы, потому что каждый столбец базы данных nvarchar, а не varchar, так что этого не должно быть.
Спасибо!
Вы проверили MAX (LEN()) в исходной таблице? Я бы предположил, что вы как-то выбрали запись более 35 символов, может быть, непечатаемых или конечных пробелов. Это кажется более вероятным, чем объяснение спонтанной перекомпиляции, хотя SSIS 2005 довольно старая и всегда имела более странное поведение, чем 2008 или 2012. – criticalfix
Я проверил ее и проверил LEN (city + 'a) тоже, чтобы игнорировать пробелы. (потому что LEN ('aa') и LEN ('aa') возвращает одно и то же значение. И нет записи, которая выше 35 – dn7123