ADF V1存储过程活动：如何通过SQL查询传入参数？

首先直接给你结论：ADF V1确实没有像V2里Lookup Activity那样原生支持直接把SQL查询结果作为存储过程的输入参数。V1的Sproc Activity只能用静态值、管道参数或者系统变量来传参，没法直接关联查询结果。不过咱有替代方案，两种思路可以解决这个问题：

方案1：用存储过程嵌套（最推荐） #

既然ADF V1做不了查询传参的逻辑，那把这个逻辑移到SQL Server端就行——写一个“包装层”存储过程，先完成查询获取参数值，再调用目标存储过程。

举个具体的例子，你可以创建这样一个中间存储过程：

CREATE PROCEDURE dbo.wrapper_testProc
AS
BEGIN
    -- 先从table_A查询需要的参数值（这里可以加你需要的过滤条件）
    DECLARE @param1_value NVARCHAR(MAX)
    SELECT @param1_value = column1 FROM table_A WHERE [你的过滤条件]

    -- 调用目标存储过程，传入查询到的值
    EXEC dbo.testProc @param1 = @param1_value
END

之后在ADF V1的Sproc Activity里，直接配置调用dbo.wrapper_testProc就行，不需要额外传参数——所有的参数获取和传递逻辑都在SQL端完成了，简单又省心。

方案2：自定义.NET活动（适合复杂场景） #

如果你的业务逻辑比较复杂，或者必须在ADF层面处理参数获取，那可以用ADF V1的Custom Activity。你需要写一段.NET代码，逻辑大概是：

• 连接到SQL Server，执行查询获取column1的值
• 再调用dbo.testProc并传入这个值
• 把代码打包成程序集，部署到Azure云服务或者本地节点，然后在ADF里配置Custom Activity来运行这段代码

不过这个方式需要开发和部署代码，相对麻烦一些，除非必要，否则优先用方案1。

总的来说，ADF V1虽然没有原生的Lookup功能，但通过存储过程嵌套完全可以实现你要的需求，这也是大多数人在V1里处理这类场景的首选方式。

内容的提问来源于stack exchange，提问作者Sam