SSIS pkg с подключением к плоскому файлу с меньшим количеством столбцов потерпит неудачу

Предположим, что плоский файл F1.txt, столбец MyCol1 и пакет Pkg1 загружают указанный файл на сервер SQL.

Нет проблем, верно? Правильно.

Теперь предположим, что плоский файл F2.txt, столбцы MyCol1, MyCol2 и тот же пакет Pkg1 загружают указанный файл на сервер SQL.

Мы внесем несколько изменений в Pkg1 и presto - он загружает F2.txt как сон.

Теперь мы кормим его F1.txt и там все ухудшается.

Кстати, это не ограничивается плоскими файлами, но носит более общий характер.

Любые предложения о том, как запустить legacy-данные в одном пакете, приветствуются.

ТИА

Питер

 rvphx21 мая 2012 г., 16:08
Срок действия метаданных пакета истекает, как только вы меняете источник. Сказав это, я предполагаю, что когда вы пытаетесь загрузить F2.txt, вы фактически перемещаете F1.txt в другое место.
 David Benham21 мая 2012 г., 17:23
Вы можете создать поток данных для каждого типа метаданных. Затем перед потоками данных создайте одну задачу сценария, которая определяет, какой поток данных следует использовать на основе макета файла.
 rvphx21 мая 2012 г., 16:17
Мой ответ должен быть наоборот (я не нашел кнопку редактирования для моего комментария) "Говоря так, я предполагаю, что когда вы пытаетесь загрузить F1.txt, вы фактически перемещаете F2.txt в другое место & quot;

Ответы на вопрос(1)

Решение Вопроса

Похоже, у вас есть две проблемы здесь. Первое - это понимание того, как использовать диспетчеры соединений. Для ввода плоских файлов вам, как правило, будет удобнее создавать диспетчер соединений для каждого макета файла. Файл 1 выглядит как (Column1), а файл 2 выглядит как (Column1, Column2)? Это означает, что нужно определить 2 разных менеджера соединений с плоскими файлами.

Если у вас есть 2 версии файла 2: одна, в которой Column1 имеет числа, а другая - в Column1, содержащем символьные данные, для них потребуется 2 уникальных диспетчера соединений (всего 3).

Хорошая новость относительно вышеизложенного состоит в том, что изменения имен файлов тривиальны и не требуют создания уникального диспетчера подключений. F1.txt, F1_20120501.txt, F1.good.txt и т. Д. Будут обслуживаться диспетчером соединений, который вы определили для этого макета. Вам просто потребуется использовать выражение в свойстве ConnectionString данного диспетчера подключений, чтобы обновить текущий пакет во время выполнения.

Теперь, когда у вас есть все эти менеджеры соединений с плоскими файлами, вам нужно их использовать. Это волшебство происходит в задачах потока данных. Поток данных очень привередлив в метаданных, используемых в нем. Когда вы разрабатываете поток данных, вы заключаете контракт с SSIS, и если вы пытаетесь нарушить его, превращая символьное поле в поле даты или не предоставляя все столбцы, пакет не будет проверяться, поскольку вы не удерживаете до конца сделки. Решение этой проблемы заключается в том, что вам снова потребуется определить несколько потоков данных вокруг различных диспетчеров соединений, которые нужны вашим пакетам.

После всего этого вам просто понадобится координатор, чтобы просмотреть исходные файлы, чтобы определить, какой поток данных должен быть выполнен. Я привел пример по этому вопросуСоздать пакет служб SSIS для импорта из одного из многих источников данных

Был также похожий вопрос, где я предложил решение, которое может представлять интересЗадача служб SSIS для несогласованного импорта столбцов? Это действительно зависит от ваших правил обработки.

Если вы пытаетесь объединить / повторно использовать бизнес-логику в своих пакетах служб SSIS, то я бы искал подход с использованием различных потоков данных для преобразования отдельных источников в единое хранилище данных (необработанный файл, промежуточная таблица с множеством пустых столбцов и т. Д.). ).

 webhiker22 мая 2012 г., 10:19
Я думаю, что Billinkc (это был бы Билл в KC?) Подытоживает это хорошо. Большое спасибо за беспокойство, я посмотрю на оба.

Ваш ответ на вопрос