处理源LOB列时避免使用“逐行”获取方法

我有一个旧的PostgreSQL数据库源（ODBC），我正尝试使用SSIS迁移到新的SQL Server模式。我收到警告说：

强制执行“逐行”读取方法，因为该表具有LOB列。列的内容是LOB

问题是，该列中的任何一个都不必真正是LOB。有一些是TEXT类型，但可以很容易地放入varchar（max）中。但是，甚至更陌生的人，大多数已经是 varchars，但是似乎将varchar（128）上的所有内容都视为是LOB（在预先的属性中，数据类型为DT_NTEXT）。

我事件尝试执行一条手动SQL命令，其中我在select语句中将每种字符串类型显式转换为适当长度的varchar，并且在ODBC源中仍将它们设置为DT_NTEXT。

我不是DBA，所以我做的事情很愚蠢是完全有可能的。我只想知道确保类型最终成为varchars的最佳方法，这样我就可以批量提取。有任何想法吗？

如果有问题，我将在Visual Studio 2013中使用SSIS-BI 2014。

我对大于128的varchar使用数据转换作为NTEXT，但最终为我消除了错误的是将Validate External Data设置为False。

显然，这只是归结为SSIS将大于128的任何varchar视为NTEXT。不知道为什么。但是，我可以进入ODBC源的高级属性，然后将类型改回类似DT_WSTR。这似乎大部分都起作用。

但是，我确实确定我要处理的一些表实际上在其某些TEXT列中承载了4000字节以上的数据，因此不幸的是，我不得不将这些列保留为DT_NTEXT以防止截断（SSIS不会让您将DT_WSTR类型设置为超过4000个字节）。我想在这些情况下，我只是坚持逐行读取，但是至少我能够修复一些表。

这个解决方案为我工作：

我通过更改数据源属性中的Max Varchar参数消除了该错误。转到连接管理器。选择连接字符串旁边的构建选项。单击连接按钮以访问更多选项。更改最大Varchar的值。

在我的情况下，源是Filemaker ODBC，它也将长文本视为LOB数据类型。由于该表具有LOB列，因此由于逐行获取方法的性能极大降低而使我的程序包长时间挂起。因此，在部署时，它通常会在很长一段时间后超时，并最终失败。

我正在分享实际的解决方案，对我来说就像是一种魅力。一天价值超过3万个LOB类型数据提取对我来说大约花费了10分钟：：

将DefaultBufferMaxRows降低到1，并将DefaultBufferSize增加到最大，即100 MB。然后通过选中选项“将文本视为长整型varchar”来更改源ODBC DSN。并将数据类型按原样从源映射到目标（源高级编辑器中没有任何更改）。