嘿，我来帮你捋捋这个问题～

你的判断方向没错，问题确实出在表名的大小写差异上，虽然Oracle默认不区分大小写，但这里有个很容易踩的坑：

核心原因 #

Oracle只有在表名是纯大写/小写且创建时没加双引号的情况下才不区分大小写；但如果生产环境的saLes是用双引号创建的（比如执行了CREATE TABLE "saLes" (...)），那这个表名就变成了大小写敏感的标识符——这时候Power BI如果直接用不带双引号的表名去查询，Oracle会自动把它转成大写SALES，自然找不到实际存在的"saLes"表，就会报“Key does not match any row in the table”的错误。

而预生产的sales是纯小写，Oracle默认会转成大写SALES，和实际表名匹配，所以能正常刷新。

具体解决步骤 #

给你几个实操方案，按顺序试：

1. 先确认生产表的实际定义
   登录生产Oracle环境，执行这条SQL看看表名的真实状态：

   SELECT table_name FROM user_tables WHERE lower(table_name) = 'sales';
   

   如果返回的table_name是saLes（带大小写混合），就说明这个表是带双引号创建的，必须用带引号的方式访问。

2. 修改Power BI的M查询逻辑
   如果你是用自定义SQL导入数据，原来的代码可能类似：

   Source = Oracle.Database(SchemaParameter, [Query="SELECT * FROM " & TableNameParameter])
   

   要改成给表名加上双引号（注意M语言里双引号需要用三个来转义）：

   Source = Oracle.Database(SchemaParameter, [Query="SELECT * FROM """ & TableNameParameter & """"])
   

   如果你是通过“导航器”选择表的方式，需要修改导航步骤的代码，把参数化的表名用双引号包裹，确保生成的SQL是带引号的表名。

3. 本地测试后再发布
   在Power BI Desktop里切换参数到生产环境（Schema和TableName都改成生产的saLes），先刷新验证能正常加载数据，再发布到服务端。

4. 服务端参数配置要准确
   发布后在Power BI服务里修改参数时，表名字段要严格输入saLes（大小写完全匹配），不要写错，再尝试刷新。

额外提醒 #

别被“Oracle不区分大小写”的常识误导——只有当表名是纯大小写且创建时未加双引号，Oracle才会自动统一转成大写；一旦用双引号创建了混合大小写的表名，就必须严格匹配并带双引号访问，Power BI只是忠实地把查询语句传递给Oracle，所以这里的关键就是让Power BI生成带双引号的表名查询。

备注：内容来源于stack exchange，提问作者user8165644