我开发了一个简单的 SSIS 包,它将打开一个 csv 文件,选择一些列,添加两个派生列,然后将结果复制到一个文件中。
这在我构建它的 visual studio 中有效(即使它需要很长时间)。问题是当我尝试将它部署到我们的 sql server 时它失败了。
它一直说:
"The specified parameter value string is too long. The string must be no more than 8000 characters."
但我不知道它在说什么,因为我的专栏都没有超过 1000 个字符。
关于此错误的信息不多,但行数(400,000+)是否可能是问题的根源?
这不是您的数据的问题 - 这是您的包裹的问题。通常,这是查询大小的问题。
似乎在内部,SSIS 在某处使用了 varchar(8000) 值,而实际上可以使用 varchar(max) 值。当您遇到此限制时,您会收到此不明确的错误。
有几种方法可以解决这个问题。您可以缩短查询(通过删除过多的空格、用制表符替换空格、压缩缩进等)。
您还可以将查询拆分为多个变量或参数,然后在执行查询之前将这些部分与表达式任务连接在一起。
根据查询,您还可以将其转换为一个或多个存储过程或视图,并在您的包中调用它们。
但是,如果您将查询保留在包内,则需要将其长度(或其片段的长度)减少到 8000 个字符以下。玩得开心。
玩得开心——没有什么比重构查询更有趣的了。
如果您使用的是 SQL Server 2008 或更新版本,则可以使用VARCHAR(MAX)
varchar(max) 应该可以正常工作,以下是 SQL:
我有一个完全相同的错误,也没有长 sql 字符串,所以我假设分辨率即使不完全相同也可能相似。我一直在消除从我的包裹中移除东西,直到我弄清楚是什么控制给我带来了问题。在我的例子中,原因是自定义 TF 连接的名为 FilterObjectState 值的属性上有一个非常长且奇怪的字符串(我通常复制并粘贴具有这些连接的控件,这可能不是一个好主意)。该字符串超过 4000 个字符。一旦我摆脱了部署的项目和 8000 个字符的错误就停止了。连接属性也与项目文件一起保存,因此在记事本中查看项目文件中的长字符串可能是调试此问题的另一个(可能更容易)开始......
所以我发现了问题所在。
原来问题的根源是我正在处理的多个文件的文件位置字符串的长度。如果字符串超过 4000 个字符,而不是错误消息建议的 8000 个字符,SSIS 将无法处理。