为什么 STR 的可用性不一致？
当我创建 OLE DB 源时，我可以使用以下表达式：
STR(1234.545, 8, 2)
但是当我使用派生列流任务时，该表达式是非法的。设计时错误指出：
无法识别功能“SET”。函数名称可以是 不正确或不存在。
我想知道为什么该函数不可用于派生列任务。一般来说，我想知道管理哪些函数实际上可用的规则，或者可能是派生列任务可用的函数列表。
When I create a OLE DB source, I can use the following expression:
STR(1234.545, 8, 2)
But when I use a Derived-Column flow task, that expression is illegal. The design-time error states:
The function "SET" was not recognized. Either the function name is
incorrect or does not exist.
I'd like to know why the function is not available to the Derived-Column task. And in general, I'd like to know the rule governing which functions are in fact available, or perhaps a list of the functions that are available to the Derived-Column task.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
要了解派生列转换中可用的函数，请查看集成服务表达式参考。特别是，您可能对字符串函数和其他函数（SSIS 表达式）感兴趣
为什么 SET 在 OLE DB 中工作而不是在派生列中工作是相当简单的，它们是不同的技术。 set 语句针对数据库运行，是一种声明式语言 (SQL)，而派生列表达式是一种命令式语言 (vb/c#/etc)。
顺便说一句，我不知道参考 SET 语句会做什么，也不知道适用于什么 OLE DB 提供程序。也许这只是一个例子。
To answer what functions available in a Derived Column Transformation, look at Integration Services Expression Reference. In particular, you are probably interested in String Functions and Other Functions (SSIS Expression)
Why SET works in OLE DB and not in derived column is rather straight forward, they're different technologies. The set statement runs against a database and is a declarative style language (SQL) while the derived column expression is an imperative style language (vb/c#/etc).
BTW, I have no idea what the reference SET statement would do or what OLE DB provider that would work for. Perhaps it was just an example.