2013-03-12 2 views
4

Я использую Задачу потока данных в SSIS для получения данных с одного сервера (SQL Server 2005) на другой (SQL Server 2008 R2). В OLE DB Source соединение Я использую команду SQL для получения данных. В этой команде я уже литье содержания как определенный тип данных:.Почему мои CASTS, по-видимому, игнорируются в SSIS?

SELECT 
CAST(column1 AS VARCHAR(10)) AS NameColumn1 
,CAST(column2 AS INT) AS NameColumn2 
,CAST(REPLACE(REPLACE(REPLACE(REPLACE(column3, CHAR(10), ''), CHAR(13), ''), CHAR(9), ''), ';', '-') AS VARCHAR(100)) AS NameColumn3 
,CAST(REPLACE(REPLACE(REPLACE(REPLACE(column4, CHAR(10), ''), CHAR(13), ''), CHAR(9), ''), ';', '-') AS VARCHAR(255)) AS NameColumn4 
... 
FROM (etc.) 

(Обратите внимание, что забросы отливки к исходному типу данных значений столбцов в базе данных источника Таким образом, типа данных column1 является первоначально VARCHAR(10), что из column4 изначально VARCHAR(255), и так далее)

Эти слепки используются потому, что далее в пакете я получил следующее предупреждение для column3 и column4:.

Validation ва rning. [...] Усечение может произойти из-за вставки данных из колонки потока данных «column4» с длиной 8000 до базы данных колонка «column4» с длиной 255.

Кажется, как будто слепки не работают, потому что предупреждения об усечении для столбцов3 и столбца4 продолжают поступать. (Я уже установили предупреждение усечения в OLE DB Источник в Игнорировать отказ, но это, кажется, не делают разницы.)

Я не могу найти что-нибудь на этом онлайн и воли в данное время «разрешите» это, импортировав столбцы как VARCHAR(8000). Но я хотел бы знать, в чем причина такого поведения в SSIS. Кто-нибудь понял?

+1

ru, используя любой «производный столбец», преобразовывая его длину до 8000, потому что ошибка явно указывает, что 'column4' имеет длину' 8000' в 'исходной таблице', и вы пытаетесь сопоставить столбцу в 'destination 'имеет длину' 255'? – praveen

+0

Нет, поскольку 'column4' - это тип данных' VARCHAR (255) 'в исходной таблице. Эта длина 8000, кажется, выходит из тонкого воздуха ... – Josien

+0

«Правой кнопкой мыши» на источнике OLEDB и вручную измените длину для столбца 4 и на всякий случай проверьте свойство 'ValidateExternalMetadata' в' Destination' или 'Source'. Это должно быть 'true' – praveen

ответ

4

Перейдите в Advabnced Properties исходного компонента и проверьте размер 3-го и 4-го столбцов (в свойствах ввода и вывода). Если они уже были рассчитаны как varchar (8000), вам придется вручную их изменять.

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

+4

В качестве альтернативы удалению компонента просто измените запрос на что-то вроде 'SELECT 1 as tmp' , После нажатия кнопки «ОК» метаданные выходного буфера будут сброшены в один столбец с типом данных int. Затем снова вставьте свой запрос. Основная проблема заключается в том, что исходные компоненты не всегда заботятся, если исходный столбец меньше, чем первоначально объявлено. Логика кажется «String 255 подходит для строки 8000, поэтому нет необходимости обновлять метаданные». – billinkc

+0

@billinkc: ваше предложение сделало трюк! По-видимому, проблема была связана с тем, что метаданные не обновлялись ... Спасибо за ваши предложения! Узнал что-то новое сегодня :-) – Josien

 Смежные вопросы

  • Нет связанных вопросов^_^