Проверка типов данных столбцов назначения плоских файлов

Question

Поле исходной базы данных типа INT считывается через источник OLE DB.Это в конечном счете записано в Место назначения Плоского файла.Диспетчер соединений с плоскими файлами назначения> Страница Advanced сообщает об этом как four-byte signed integer [DT_I4].

. Этот тип данных заставил меня думать, что он указан в двоичном виде.Понятно, что нет.Я был удивлен, что это не было более общим numeric [DT_NUMERIC].

. Я изменил настройку этого типа на single-byte signed integer [DT_I1].Я ожидал, что это потерпит неудачу, но это не так.Процесс дал один и тот же результат, даже если значение поля всегда было> 127. Почему это не сработало?

Некоторые из полученных значений:

1679576722
1588667638
1588667638
1497758544
1306849450
1215930367
1215930367
1023011178
1932102084 

Очевидно,вне диапазона single-byte signed integer [DT_I1].

Как связанный вопрос, возможно ли выводить двоичные данные в плоский файл?Если да, какие настройки и где следует использовать?

Answer 1

Проверка типов данных

Я думаю, что эта проблема связана с используемым диспетчером соединений, поскольку проверка типов данных (вне конвейера) не выполняется службами Integration, а выполняется поставщиком услуг.:

• OLEDB для Excel и Access
• SQL Database Engine для SQL Server
• ...

Когда дело доходит до менеджер соединений с плоскими файлами , он не гарантирует согласованность типов данных , поскольку все значения хранятся в виде текста .Например, попробуйте добавить диспетчер соединений с плоскими файлами, выберите текстовый файл с именами, попробуйте изменить типы данных столбцов на «Дата» и перейдите на вкладку «Предварительный просмотр столбцов», в которой все столбцы будут отображаться без проблем.Он заботится только о разделителе строк, разделителе столбца, квалификаторе текста и общих свойствах, используемых для чтения из плоского файла. (аналогично классу TextFieldParser в VB.NET)

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

Двоичный вывод

Вы должны преобразовать столбец в двоичный файл в пакете и отобразить его в столбце назначения.Например, вы можете использовать для этого компонент скрипта:

public override void myInput_ProcessInputRow(myInputBuffer Row)
  {

  Row.ByteValues=System.Text.Encoding.UTF8.GetBytes (Row.name);

  }

Я не пробовал, будет ли это работать с производным столбцом или преобразованием преобразования данных.

Ссылки

• Преобразование ввода в (DT_BYTES, 20)
• DT байтов в SSIS

Answer 2

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

Похоже, что SSIS не применяет метаданные назначения;однако, это обеспечит применение метаданных источника.Я создал тестовый файл с диапазонами от -127 до 400. Я проверил это в следующих сценариях:

• Тест 1: Диспетчеры соединений с исходным и целевым плоскими файлами с подписанными однобайтовыми даннымитип.
• Результат 1: Сбой
• Тест 2: Источник подписан 4 байтами, а пункт назначения - 1 байтом.
• Результат 2: Pass

Проверка метаданных конвейера служб SSIS заботится только о метаданных ввода, соответствующих ширине конвейера.Похоже, что все равно, что на выходе.Тем не менее, он предлагает вам возможность назначить в качестве пункта назначения любой исходящий источник, чтобы он мог проверять и выдавать предупреждение, если метаданные назначения (т. Е. SQL Server) совпадают или нет.

Это было неожиданнорезультат - я ожидал, что он потерпит неудачу, как и вы.Интуитивно понятно, что тот факт, что он не потерпел неудачу, все еще имеет смысл.Так как мы пишем в файл CSV, то нет способа контролировать, какие метаданные необходимы.Но если мы подключим это к месту назначения SQL Server, а метаданные не будут совпадать, то SQL Server будет недоволен данными за пределами допустимого диапазона (см. Мой другой ответ).

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

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

Дополнительная информация

TL DR: TinyInt сохраняется как тип данных без знака в SQL ServerЭто означает, что он поддерживает значения от 0 до 255. Таким образом, допустимо значение больше 127 - до 255. Все, что больше, приведет к ошибке.

Размер байта указывает максимальное количество возможных комбинаций, гдезнак / без знака указывает, делится ли диапазон между положительными и отрицательными значениями.

• 1 байт = TinyInt в SQL Server
• 1 байт равен 8 битам = 256 комбинациям
• Диапазон подписи: от -128 до 127
• Диапазон без знака: от 0 до 255

Важнообратите внимание, что SQL Server не не поддерживает прямую подпись типов данных.Я имею в виду, что нет способа установить целочисленные типы данных (т. Е. TinyInt, Int и BigInt) как подписанные или неподписанные.

• TinyInt без знака
• Int и BigInt со знаком

См. Ссылку ниже: Максимальный размер поля автоидентификации SQL Server

Если мы попытаемся установить для TinyInt любое значение, выходящее за пределы диапазона без знака (например, -1 или 256), то получимследующее сообщение об ошибке:

Вот почему вы смогли установить значение больше 127.

Int ОшибкаСообщение:

Сообщение об ошибке BigInt:

Что касается столбцов Identity, если мы объявим столбец Identity как Int (т.е., 32 бита ~ = 4,3 миллиарда комбинаций) и установите начальное значение в 0 с шагом 1, после чего SQL Server до конца остановится только на 2 147 483 647 строк, что является максимальным значением со знаком.Но у нас короткая половина диапазона.Если мы установим начальное значение на -2 147 483 648 (не забудьте включить 0 в диапазон), то SQL Server будет увеличивать весь диапазон комбинаций перед остановкой.

Ссылки:

Типы данных SSIS и ограничения

Максимальный размер поля автоматической идентификации SQL Server