我正在实现一个 x64 应用程序，连接到 Oracle。
我应该使用什么驱动程序，以确保用户安装的客户端版本无关紧要。
所以，现在我正在使用 x64 和 x86 ODP.NET 驱动程序构建我的版本，但我担心当用户拥有旧/新版本的 Oracle 客户端 (ODP. NET) 已安装。
我应该改用 OleDB 或 System.DataAccess 驱动程序以避免这个问题，还是根本不会出现问题？
PS：我之前使用的是 ODBC 驱动程序，但在 x64 上有已知的错误，所以这不是一个选项。
【问题讨论】：
哦，甲骨文的“快乐”... 好吧，基本上，我从不关心 x64 版本，我只是专门为 32 位编译了我的程序，所以如果这是一个硬性要求，并不是所有的东西都适合你。
但我获得版本不可知论的方法是根本不使用任何客户端安装的驱动程序；相反，我在我的应用程序目录中部署了 Oracle Instant Client 的库和 ODP 二进制文件； ODP 将使用 OCI（即时客户端）文件（如果可访问）。这是最简单的出路，我很高兴我这么轻松地解决了它，尽管这方面的信息并不容易获得。
对于当前版本（至少在我上次构建应用程序时它们是最新的），11g，ODP 和 OCI 的组合确保了与版本 9-11 的兼容性。
现在，当然，OCI 相当大（如果有记忆，仅英文版会更小，“仅”35 ish MB），但我不得不忍受它（部署对我来说不是一个大问题） .此外，我还依赖于一个已经 50-ish MB 的库——其中大部分在 XML 序列化程序集中！不要让我开始......
希望这会有所帮助！
【讨论】：
恐怕这行不通。无论您使用什么驱动程序，都直接或间接在同一进程中使用本机 OCI.DLL。在您的情况下，它必须是 64 位版本。因此，您的应用程序将无法使用 32 位 OCI.DLL。
要解决此问题，您有两种选择：
编写一个单独的 32 位应用程序，负责访问 Oracle 并以某种方式与该应用程序通信。
嵌入 64 位版本的 Java VM 并通过 OJDBC（独立于 OCI.DLL 的唯一选项）访问 Oracle。
但我想，这些都不是很现实的选择。
【讨论】：