一、本地正常但同事端异常的可能原因 #

• 隐私设置未完全生效：你本地可能设置了全局隐私级别为「无」，但同事可能仅修改了单个数据源的隐私设置，未在Power Query选项中配置全局隐私规则；不同区域的O365对隐私校验逻辑存在细微差异，也可能导致跨源检查触发报错。
• 数据源识别差异：同事连接s-tcmsql102服务器的环境（如VPN、AD域身份）与你不同，Power Query将其识别为新的外部数据源，即便手动设置隐私级别，仍会因跨源引用（内部单元格+新外部数据源）触发规则限制。
• 命名单元格作用域问题：若PartNumber是工作表级命名单元格，同事的德语版Excel默认工作表名称（如Tabelle1）与你本地的（如Sheet1）不一致，导致命名单元格引用失效，间接触发查询报错。
• Power Query缓存差异：本地查询已缓存运行状态，无需重新触发跨源校验；同事打开工作簿后首次刷新，需重新解析数据源关系，触发隐私检查逻辑。

二、重构查询：安全传递PartNumber到SQL WHERE子句 #

推荐以下两种方法，彻底规避跨源隐私问题：

方法1：使用Power Query参数替代命名单元格 #

1. 在Power Query编辑器中，点击「主页」>「参数」>「新建参数」，创建名为PartNumber的文本类型参数，可选择绑定到你的命名单元格作为默认值。
2. 修改SQL查询语句直接引用参数：

let
    SourceX = Sql.Database("s-tcmsql102", "tcm102",
    [Query="Select * from Standard_cost_by_assembly where ID_ITEM_PAR = '" & PartNumber & "'"])
in
    SourceX

参数属于Power Query内部输入，不会被识别为独立数据源，可避免跨源隐私校验。

方法2：使用参数化SQL查询（更安全，防SQL注入） #

利用Power Query原生参数化能力替代字符串拼接：

let
    PartValue = Excel.CurrentWorkbook(){[Name="PartNumber"]}[Content]{0}[Column1],
    SourceX = Sql.Database("s-tcmsql102", "tcm102",
    [Query="Select * from Standard_cost_by_assembly where ID_ITEM_PAR = @Part",
     QueryParameters = [Part = PartValue]])
in
    SourceX

该方式通过原生参数传递值，既解决跨源隐私问题，又杜绝SQL注入风险，兼容性更强。

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