У меня есть устаревший источник базы данных PostgreSQL (ODBC), который я пытаюсь перенести на новую схему SQL Server с использованием служб SSIS. Я получаю предупреждение:
Метод извлечения 'Row by Row' применяется потому, что в таблице есть столбцы LOB. Содержимое столбца LOB
Дело в том, что ни один столбец не нужен быть большим. Есть несколько типов TEXT, но они могут легко поместиться в varchar (max). Тем не менее, даже более странно, что большинство из них уже являются varchars, но кажется, что все, что касается varchar (128), обрабатывается так, как если бы это был LOB (заранее свойства, тип данных - DT_NTEXT).
Я попытался выполнить ручную команду SQL, в которой я явно приводил каждый тип строки к varchar соответствующей длины в операторе select, и они все еще устанавливаются как DT_NTEXT в источнике ODBC.
Я не администратор, поэтому вполне возможно, что я делаю что-то действительно глупое. Я просто хотел бы знать, как лучше всего убедиться, что типы заканчиваются как varchars, чтобы я мог получать пакетные данные. Есть идеи?
Если это имеет значение, я использую SSIS-BI 2014 внутри Visual Studio 2013.
источник
varchar(max)качестве краткого изложения то, что данные столбца могут соответствовать максимальному размеру varchar, который составляет около 4000, для целей SSIS, я думаю. Я на самом деле ничего не бросаюvarchar(max); тем не менее, я использовал несколько столбцовvarchar(4000), чтобы быть в безопасности.Ответы:
Очевидно, это сводится к тому, что SSIS рассматривает любой varchar, размер которого превышает 128, как NTEXT. Не уверен почему. Однако я могу перейти к расширенным свойствам источника ODBC и изменить типы обратно на что-то вроде DT_WSTR. Который, кажется, работает по большей части.
Однако я определил, что некоторые из таблиц, с которыми я имею дело, в некоторых из своих столбцов TEXT переносят более 4000 байтов, поэтому мне, к сожалению, приходится оставлять эти столбцы как DT_NTEXT для предотвращения усечения (SSIS не позволяет Вы устанавливаете тип DT_WSTR с более чем 4000 байтов). Полагаю, в этих случаях я просто застрял с построчным извлечением, но, по крайней мере, мне удалось исправить несколько таблиц.
источник
Я использовал Преобразование данных для varchar больше 128 в качестве NTEXT, но в итоге мне удалось устранить ошибку - установить Validate External Data в False.
источник
Это решение сработало для меня:
Я удалил ошибку, изменив параметр Max Varchar в свойстве источника данных. Зайдите в диспетчер соединений. Выберите опцию сборки рядом со строкой соединения. Нажмите на кнопку подключения, чтобы получить доступ к дополнительной опции. Измените значение Max Varchar.
источник
В моем случае источником является ODBC Filemaker, который также обрабатывает длинный текст как тип данных LOB. Мой пакет долгое время зависал из-за чрезмерного снижения производительности для метода извлечения строк строкой, потому что в таблице есть столбцы LOB. Таким образом, будучи развернутым, он использовал тайм-аут после долгого времени и в конечном итоге терпел неудачу.
Я делюсь фактическим решением, которое сработало для меня. Один день стоимостью более 30 тыс. Фунтов данных занял у меня около 10 минут:
Уменьшите DefaultBufferMaxRows до 1 и увеличьте DefaultBufferSize до максимального значения, т.е. до 100 МБ. Затем измените исходный DSN ODBC, установив флажок «рассматривать текст как длинный varchar». И сопоставьте типы данных от источника к цели (без каких-либо изменений в расширенном редакторе исходного кода).
источник