通过32位ODBC即时客户端访问Oracle NUMBER(14)列的优化方案咨询

• SQL语句显式类型转换（改造成本最低）
  无需调整应用侧OID的double类型定义，仅需修改涉及OID查询/条件匹配的SQL语句，对传入参数显式指定转换为列的原生类型：WHERE OID = CAST(? AS NUMBER(14))。该方式会强制Oracle对参数而非表列执行类型转换，不会触发to_binary_double隐式转换，原有OID列索引可正常生效，无需修改数据库Schema，也不需要调整RFX绑定逻辑。
• 自定义RFX 64位整数绑定函数
  你遇到的ODBC驱动不支持BigInt的问题，本质是MFC默认提供的RFX函数集没有实现long long类型的绑定逻辑，而非32位Oracle Instant Client ODBC驱动本身不支持64位整数。你可以参考MFC RFX的实现逻辑，自定义RFX_Int64函数，绑定的时候指定C数据类型为SQL_C_SBIGINT、SQL数据类型为SQL_BIGINT，只要你的Instant Client版本高于10gR2，都可以正常兼容，直接使用__int64类型传递OID，完全避免浮点转换问题。
• 字符串传参配合显式转换
  若驱动版本确实过旧不支持64位整数绑定，可以保留OID的字符串类型定义，同样在SQL中对参数做显式转换：WHERE OID = TO_NUMBER(?)。注意该场景下转换的是传入的参数值，而非表中的OID列，所以不会导致索引失效，性能和原生整数传参完全一致，优于原有double方案。
• 高低位拆分传参（极端兼容场景）
  如果上述方案都受限，可以把应用侧的__int64类型OID拆分为高32位和低32位两个32位整数参数传递，SQL中拼接成完整OID：WHERE OID = :high_val * 4294967296 + :low_val，无类型转换问题，索引可正常生效。

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