我正在实现一个x64应用程序，连接到Oracle。
我应该使用哪种驱动程序，以确保用户安装的客户端版本无关紧要。
所以，现在我正在使用x64和x86 ODP.NET驱动程序构建我的版本，但我担心当用户拥有较旧/较新版本的Oracle客户端（ODP）时，这将不起作用。 NET）安装。
我是否应该转移到OleDB或System.DataAccess驱动程序，以避免此问题，或者根本不会出现问题？
PS：我之前使用的是ODBC驱动程序，但是x64上已经存在已知错误，所以这不是一个选项。
答案 0 :(得分：2)
哦，Oracle的'快乐'...... 好吧，基本上，我从来没有打扰过x64版本，我只是将我的程序编译为32位，所以如果这是一个很难的要求，那么一切都不适合你。
但我如何获得与版本无关的只是不使用任何客户端安装的驱动程序;相反，我在我的应用程序目录中部署了Oracle Instant Client的库和ODP二进制文件;如果可以访问ODP，ODP将使用OCI（即时客户端）文件。这是最简单的出路，我很高兴我轻松解决了这个问题，尽管这方面的信息并不容易实现。
使用当前版本（至少它是我上次构建应用程序时的最新版本），11g，ODP和OCI的组合确保了与版本9-11的兼容性。
现在，被授予，OCI相当大（仅限英语的版本，如果内存服务的话只有'35-ish MB'，但是我不得不忍受它（部署对我来说不是一个大问题） 。此外，我对一个已经有50-MB的库有了另一种依赖 - 大多数都是在XML序列化程序集中！不要让我开始......
希望这有帮助！
答案 1 :(得分：0)
我担心这不起作用。无论您使用何种驱动程序，都可以在同一进程中直接或间接使用本机OCI.DLL。在您的情况下，它必须是64位版本。因此，您的应用程序将无法使用32位OCI.DLL。
要解决此问题，您有两种选择：
编写一个单独的32位应用程序，负责访问Oracle，并以某种方式与该应用程序进行通信。
嵌入64位版本的Java VM并通过OJDBC访问Oracle（唯一独立于OCI.DLL的选项）。
但我想，这些都不是很现实的选择。