Azure Data Factory中通过Lookup活动读取含管道参数的SQL查询文件时执行失败的问题排查

核心问题在于：Lookup活动读取SQL文件内容时，会把文件里的所有文本当作纯字符串返回，不会自动解析其中的Azure Data Factory (ADF) 动态表达式。也就是说你写在.sql文件里的@{activity('lkp-get-param-list').output.firstRow.PreviousFiscalYear}并没有被替换成实际的年份值，而是直接作为字符串传递给了Copy活动，导致SQL执行时出现语法错误或者匹配不到数据。

解决方案 #

这里提供两种可行的处理方式：

1. 占位符替换法（推荐） #

• 在.sql配置文件中用自定义占位符代替ADF表达式，比如：

  select 
    D_OrganizationID,
    OrgName
  FROM
    rpt.D_Organization b 
  where b.SubFiscalYear = '{PreviousFiscalYear}'
  

• 在Copy活动的sqlReaderQuery中使用动态内容，将占位符替换为实际参数值：

  replace(activity('Lookup-SQL-File').output.firstRow.Content, '{PreviousFiscalYear}', activity('lkp-get-param-list').output.firstRow.PreviousFiscalYear)
  

  （注：Lookup-SQL-File是你读取.sql文件的Lookup活动名称，根据实际名称修改；如果文件内容是多行的，确保Lookup读取时能正确获取完整SQL文本）

2. 参数化查询拼接法 #

• 在.sql文件中写好带参数占位符的SQL，比如：

  select 
    D_OrganizationID,
    OrgName
  FROM
    rpt.D_Organization b 
  where b.SubFiscalYear = @p1
  

• 在Copy活动的sqlReaderQuery中拼接参数值：

  concat(activity('Lookup-SQL-File').output.firstRow.Content, ' ', '@p1=', activity('lkp-get-param-list').output.firstRow.PreviousFiscalYear)
  

  这种方式适合SQL本身支持参数化的场景，不过对于复杂查询，占位符替换法更直观。

排查方向 #

1. 查看Copy活动的实际执行SQL：
   进入ADF监控面板，找到失败的Copy活动，查看其输入参数，你会发现sqlReaderQuery里的@{...}表达式完全没有被解析，还是原封不动的字符串——这就是导致SQL执行失败的直接原因。
2. 验证Lookup活动的输出：
   检查读取.sql文件的Lookup活动输出，确认Content字段返回的是你写的原始SQL文本，没有任何表达式解析的迹象。
3. 测试动态内容拼接结果：
   在ADF的动态内容编辑器中，输入你准备好的拼接表达式（比如replace那一行），点击「测试」按钮，查看生成的最终SQL是否正确，参数是否被替换成了实际的年份值。

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