oracle表列名默认大写，ef core脚手架生成小写属性导致大小写不匹配；应使用--use-database-names参数或onmodelcreating中hascolumnname映射为大写，并统一建表习惯、显式标注table特性、设置useoraclesqlcompatibility("11")。
Oracle表名和列名默认大写，EF Core脚手架生成的属性名却小写
这是最常见的“大小写不匹配”源头：Oracle建表时不加双引号（如 CREATE TABLE emp (name VARCHAR2(50))），数据库内部自动转为大写 EMP 和 NAME；但EF Core脚手架（dotnet ef dbcontext scaffold）默认按原始SQL标识符字面量生成C#属性，结果得到 public string name { get; set; } —— 编译失败，因为C#标识符不能全小写开头。
解决思路不是改数据库建表习惯（多数老系统不允许），而是让EF Core统一把列名映射为大写：
- 在
OnModelCreating中对所有属性调用HasColumnName，传入ClrPropertyInfo.Name.ToUpper() - 如果使用脚手架生成模型，需配合
--use-database-names参数（EF Core 7+），否则默认会做PascalCase转换，加剧大小写错位 - 注意：该映射只影响列名映射，不影响查询时的SQL生成逻辑——生成的SQL仍会用大写列名，与Oracle实际一致
ORA-00942 表或视图不存在，其实是大小写没对齐
运行时抛出 ORA-00942，但表明明存在，大概率是EF Core里写的表名大小写和Oracle中实际注册的不一致。比如Oracle里建的是 "Pub_Employee"（带双引号），而代码里写的是 [Table("pub_employee")] 或漏了 [Table("Pub_Employee")]。
关键检查点：
- 用SQL*Plus或SQL Developer执行
SELECT table_name FROM user_tables，确认表名真实拼写（含大小写和双引号） - 若表名含小写或特殊字符，必须在C#模型上显式标注
[Table("Pub_Employee")]，且字符串字面量要和数据库中完全一致 - 避免混用：不要一部分表用双引号建，一部分不用；统一用大写无引号建表最省事
UseOracleSQLCompatibility("11") 不只是版本适配，也影响大小写解析行为
UseOracleSQLCompatibility("11") 看似只为兼容Oracle 11g语法，但它还隐式启用了更宽松的标识符解析模式。某些EF Core Oracle提供程序（尤其旧版 Oracle.EntityFrameworkCore 3.19.x 之前）在未指定兼容性时，会对未加引号的表名做额外小写化处理，导致元数据获取失败。
实操建议：
- 连接配置中务必加上
b => b.UseOracleSQLCompatibility("11")或"12"，取决于你连的是11g还是12c+ - 不要依赖
UseOracle(connectionString)的无参重载——它可能触发默认兼容模式，而该模式在不同提供程序版本中行为不一致 - 该设置不影响运行时SQL执行，只影响EF Core初始化阶段对系统视图（如
ALL_TAB_COLUMNS）的查询方式
忽略大小写的查询（如 WHERE UPPER(name) = UPPER(?)）会丢索引，别直接这么写
业务层需要“不区分大小写查询”时，容易想到 WHERE UPPER(name) = UPPER(:p)。但Oracle无法用上 name 字段上的普通B-Tree索引，会退化为全表扫描。
真正可行的路径只有两条：
- 建函数索引：
CREATE INDEX idx_emp_name_upper ON emp(UPPER(name))，然后EF Core中保持原字段映射，查询时仍用.Where(x => EF.Functions.Upper(x.Name) == input.ToUpper()) - 改数据库排序规则（仅限12c+）：在列级设
COLLATE BINARY_CI，但EF Core目前不支持自动识别该属性，需手动在迁移中执行ALTER TABLE ... MODIFY name VARCHAR2(50) COLLATE BINARY_CI
最常被忽略的一点：函数索引必须和查询中使用的函数完全一致（包括嵌套、参数顺序），UPPER() 和 LOWER() 不能混用，否则索引失效。
