簡単な答え：
注：以前のクライアントに新しいODP.NETをインストールしようとしましたが、次の接続文字列を使用してデータベースに接続できました...
これは、新しいインストールの/ Network/Adminにtnsnames.oraとsqlnet.oraがないことを示しています。新しいODP.netインストールを使用して古いクライアントに問題がない場合は、古いインストールからそれらをコピーするか、TNS_ADMIN環境変数（TNS_ADMIN=C:\MyOracleFilesDir
長い答え：
新しいクライアントをインストールすると、アセンブリ解決プロセス中に古いOracle.DataAccess.dllへの参照を新しいバージョンにリダイレクトする発行元ポリシーファイルもGACにインストールされた可能性があります。次に、Oracle.DataAccessは、レジストリ内のパラメータ（DllPath）を介してクライアントを検索します。 .configファイルでdllPathを設定することにより、この場所を上書きできます。
<configuration>
<oracle.dataaccess.client>
<add key="DllPath" value="C:\yourotherpath"/>
</oracle.dataaccess.client>
</configuration>
これは一般的に私が行うことですが、これをより理解するにつれて、古いクライアントに対して新しいdllを強制していることに気付きます。古いクライアントをそのままにしておくことが目標の場合は、GACからパブリッシャーポリシーを削除することをお勧めします（完全なODACインストールでインストールされているとは思わず、ODP.netのみ）：
それらを再インストールする必要がある場合は、通常、oraclepath \ odp.net\PublisherPolicyにあります。
もう1つの、おそらくより長期的なオプションは、発行元のポリシーを無視するように古いクライアントを構成することです。http://msdn.microsoft.com/en-us/library/cf9025zt%28v=vs.80%29.aspx
最後に、2.0フレームワークと4.0フレームワークの.netコンポーネントは、ODP.netのインストール時に個別のインストールオプションであると確信しています。 2.0コンポーネントをインストールしないだけで、この問題を回避できる可能性があると思います。その点で、代わりに64ビットodp.netに対して新しいプロジェクトを開発することで、同様の回避策を実行できます。 v2.0とv4.0のように、32ビットと64ビットもお互いを認識していません。