Как добавить дополнительный столбец для обработки сообщения об ошибке в потоке данных SSIS?

Я работаю над проектом SSIS, чтобы импортировать строки вызовов (файл Excel) в базу данных SQL Server.

Вот мой поток данных:

введите здесь описание изображения

Я добавил несколько поисков для проверки строк перед процессом импорта. Первый проверяет, существует ли уже строка (сделано для предотвращения дублирования, поскольку пользователь перетаскивает файлы импорта в указанную папку). Затем другие запросы проверяют ограничения внешних ключей. Более того, все не совпадающие строки перенаправляются в другую базу данных. Таким образом, я могу проверить недопустимые строки, а затем пакет аудита сообщит мне, изменилась ли моя таблица NoMatchingRowsCall во время ввода.

Теперь я хотел бы добавить «Сообщение об ошибке» к несоответствующим строкам, чтобы проверить «в чем проблема с этой строкой?». Я думаю добавить «производный столбец» после каждого поиска (без соответствующего вывода), чтобы добавить сообщение об ошибке. Как насчет этого? Как добавить текстовое содержимое в «производный столбец»? Должен ли я использовать переменную пакета?

Вот что я хотел бы получить:

ID | C1 | C2 | C3 | ERROR_MESSAGE
1  | .. | .. | .. | Row already exists
2  | .. | .. | .. | FK error for column C1
3  | .. | .. | .. | FK error for column C2
...

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


sql-server ssis sql-server-2012 sql-server-2012-datatools
person K4timini    schedule 27.11.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Добавление производного столбца Error_Message к каждому выводу No Match даст вам то, что вы ищете. В вашем текущем дизайне вы можете просто ввести сообщение об ошибке для каждого производного столбца, поскольку для каждого потока будет один компонент производного столбца. Нет необходимости добавлять переменные, если только вы не хотите повторно использовать значения в другом месте или хранить все сообщения в централизованном месте.

Хотя пара предупреждений...

  1. Поиски по своей природе дороги, поскольку они выполняют запросы построчно. Если вы имеете дело только с небольшим количеством строк/маленькой таблицей, это может быть хорошо, но если вы просматриваете миллионы строк, вы скоро столкнетесь с узким местом. Один из способов обойти это - временно поместить ваши данные в базу данных и выполнить проверку всего набора (например, выбрать все x, которые не имеют связанной строки y, используя левое соединение). Таким образом, вы позволяете sql выполнять всю работу в пакетном режиме, что будет быстрее.
  2. Ваш текущий дизайн будет выделять только первую проблему. После того, как вы устраните проблему «нет сотрудников», в той же строке может быть несовпадение дат. В идеале вы хотите проверить все строки для всех проблем (за исключением повторяющихся строк), чтобы иметь полный набор проблем для решения. Если вы решите переключиться на использование SQL для проверки, возможно, вы могли бы добавить столбец с битовым флагом для каждого типа проблемы или один столбец с побитовым флагом, охватывающим все проблемы.
person Daryl Wenman-Bateson    schedule 27.11.2014
comment
В месяц меньше 1000 строк (с 2004 года), процесс ETL будет запускаться каждую ночь. Так что я думаю поиски не будут большой проблемой! - person K4timini; 27.11.2014