ora-00942表示“表或视图不存在”，主因是.net中sql语句的表名大小写与oracle实际存储不一致，或缺失schema前缀、权限不足；需查all_tables确认真实表名，补全schema并显式授权。
ora-00942 在 .net 应用里不是数据库连不上、也不是语法写错，而是「对象确实找不到」——但这个“找不到”往往不是因为表真没了，而是 .net 程序发过去的 sql 被 oracle 按大小写规则“认错了”。
ORA-00942 在 .NET 中最常触发的场景
- Entity Framework 或 Dapper 执行查询时抛出该异常，而同一语句在 SQL Developer 里能跑通
- 表是用 PowerDesigner 或其他建模工具生成的，SQL 脚本里带双引号（如
"QueryHistory"） - .NET 代码拼接或映射时用了 PascalCase 名（如
QueryHistory），但 Oracle 实际存的是全大写QUERYHISTORY或带引号的混合大小写
关键点：Oracle 默认把未加引号的标识符转成大写；一旦建表时用了 "QueryHistory"，那后续所有访问都必须严格匹配引号+大小写。
如何确认表名到底长什么样
在 .NET 里没法直接看元数据，得先查清楚：
- 连上数据库，运行：
SELECT table_name FROM all_tables WHERE owner = 'YOUR_SCHEMA' AND UPPER(table_name) LIKE '%QUERY%';
- 如果返回的是
QUERYHISTORY，说明没加引号建的，.NET 里用QUERYHISTORY或小写都行（Oracle 自动转） - 如果返回的是
"QueryHistory"（带双引号、含大小写），那必须在 SQL 字符串里原样写："QueryHistory"
注意：all_tables 只显示你有权限访问的表；如果查不到，可能是 schema 不对，或权限不足（见下一条）。
权限问题在 .NET 中特别容易被忽略
.NET 应用连接 Oracle 用的是某个数据库用户（比如 APP_USER），它可能：
- 没有查询目标表的权限（即使表存在）
- 权限是通过角色（如
CONNECT、RESOURCE）授予的，但 Oracle 在 PL/SQL 上下文（包括 .NET 驱动发起的隐式解析）中不识别角色权限 - 目标表在另一个 schema 下，但没加 schema 前缀，例如
SELECT * FROM QueryHistory→ 实际该表属于REPORTS.QueryHistory
检查和修复方式：
- 登录数据库，执行：
SELECT * FROM dba_tab_privs WHERE table_name = 'QUERYHISTORY';
看是否有APP_USER的SELECT记录 - 如果没有，DBA 需显式授权：
GRANT SELECT ON REPORTS.QueryHistory TO APP_USER; - 在 .NET 的 SQL 字符串里补全 schema：
SELECT * FROM REPORTS."QueryHistory"（注意大小写一致性）
EF Core / Dapper 中怎么写才安全
-
EF Core：默认用 PascalCase 映射，但 Oracle Provider（如 Oracle.EntityFrameworkCore）会自动转大写。如果你的表是
"QueryHistory"，必须手动配置：modelBuilder.Entity<queryhistory>().ToTable("\"QueryHistory\"");</queryhistory>注意双引号要转义（C# 字符串里是"\"QueryHistory\""） -
Dapper：纯字符串 SQL，完全由你控制。别依赖“看起来一样”：
- ❌
conn.Query("SELECT * FROM QueryHistory") - ✅
conn.Query("SELECT * FROM \"QueryHistory\"")（如果建表用了引号） - ✅
conn.Query("SELECT * FROM QUERYHISTORY")（如果建表没引号）
- ❌
所有表名、列名在 SQL 字符串中，只要不确定是否加过引号，就优先查
all_tables和all_tab_columns确认真实名称。
真正的难点不在“怎么改”，而在“为什么这次不行，上次却可以”。Oracle 对大小写和权限的处理是静态且严格的，而 .NET 应用往往跨环境部署（开发库 vs 测试库），表结构来源不一（脚本生成 vs 手工建），稍不注意，ORA-00942 就会卡在发布前最后一刻。
