同じアプリケーションで DAO と ADO を混在させても、実際には問題や複雑さは発生しません。あなたの質問は、いつ、なぜどちらを使用するのかということにもっと関係していると思います。
Access 開発における私自身の標準的なポリシーは、やりたいことに対して DAO が機能しない場合にのみ ADO を使用することです。たとえば、ADO を使用すると、Visual Foxpro、Oracle、MySQL などの Access 以外のデータ ストアにアクセスできます。ただし、代わりに ODBC を使用できることが多いため、これを実現するために ADO が常に必要なわけではありません。 DAO と ODBC リンク テーブル。
最近、私は ADO のみを使用する方向にギアを切り替えましたが、これは多くの経験豊富な Access 開発者の間で一般的な方法ではないことを認識しています。SQL Server 2008/2012 Express と ADO レコードセットにバインドされたフォームを使用しており、ODBC リンク テーブルの使用をまったく避けています。私の基本的な理由は、ADO を使用するといくつかのオプションと制御が増えるためです。ただし、コストはかかります。私は多くの切断されたレコードセットを使用しており、ユーザーが保存ボタンをクリックした場合にのみ、「手動で」(VBA) 変更をデータベースに書き戻します。これにより、ユーザーはフォームとそのサブフォームに一連の変更を加えることができますが、選択した場合でもキャンセルできます。切断された ADO レコードセットでは、データの変更をサーバーに取得する方法を決定するのはユーザー次第です。ただし、切断されていないレコードセットは自動的に変更を送信します。私が知る限り、サーバーからすべての追加、変更、および削除を自動的に受け取る唯一の ADO レコードセット タイプ (adOpenDynamic)フォームにバインドすることはできませんが、レコードの追加/編集/削除に ADO バインド フォームを使用できるようにしたいだけであれば、これは大きな問題ではありません。
ADO には DAO よりもパフォーマンス上の利点がなく、場合によっては実際には遅くなる可能性があるという多くの場所を読みました。一概には言えませんが、大した問題ではないと思います。ADO には、低速または不安定なネットワーク接続 (WAN/インターネットなど) でも実際にアプリケーションを動作させることができるという利点がありますが、これは DAO/ODBC では実現できません。純粋な ADO ソリューションでは、接続オブジェクトとデータのすべてのフェッチを処理する必要があります。接続とコマンドのタイムアウトを設定できます。タイムアウトが発生した場合、接続が失敗した場合など、それを処理する方法を決定するのはあなた次第です。たとえば、再接続を X 回試行できます。これは、DAO/ODBC では実際には不可能です。私の知る限り、接続オブジェクトは ODBC でも公開されていません。
特に切断されたレコードセットを使用する場合は、ADO ですべてを実行するには、さらに多くのコードが必要です。レコードセットは、コードを使用してフェッチ (または作成) する必要があります。切断されたレコードセットを使用する場合、コードを使用してデータをサーバーに書き戻す必要があります。接続されていないレコードセットを使用するか接続されているレコードセットを使用するかに関係なく、フォームのマスター/子関係は、コードを使用して手動で管理する必要があります (マスター/子リンク プロパティは使用できません)。
ADO の潜在的な欠点の 1 つは、Access Data Project を使用しない限り、レポートを ADO レコードセットにバインドできないことです。これは、MS が ADP のサポートを中止しているため、現時点では推奨されません。レポートのデータに DAO 以外のものを使用する場合は、パス スルー クエリを使用する必要があります。データ ストアが MS Access の場合、それを行う意味はありません。
バインドされたフォームとバインドされていないフォームに関する議論は、DAO と ADO に関する議論とはまったく関係がないと思います。フォームは、トレードオフをほとんど伴わずに ADO レコードセットにバインドできます。非バインド フォームは、DAO レコードセットまたは ADO レコードセットからデータを取得できますが、違いはありません。そのため、非バインド フォームと ADO は、DAO と非バインド フォームと同様に、相互に関連付けられたり関連付けられたりすることはありません。私は実際には、独自のメッセージ ボックスと特定の種類の入力ボックスまたはレコード選択ボックスを作成するためにバインドされていないフォームのみを使用しています。通常、タッチ スクリーン アプリケーションのボタンにデータを表示したい場合に、バインドを解除します。Textboxes から同様の動作を得ることができれば (そして、十分に努力すればおそらく可能になるでしょう)、バインドされていないフォームが必要になるケースはほとんどないでしょう。
バインドされていないフォームは、実際の専門家が Access アプリケーションを開発する方法であるという考えが広まっているように私には思えます。または、バインドされていないフォームがパフォーマンスを得る唯一の方法です。または、MS Access をデータ ストアとして使用していない場合は、バインドされていないフォームを使用する必要があります。しかし、これらのアイデアのどれも、精査に実際に耐えられるものではありません。フォームを ADO レコードセットにバインドすることは、完全にバインドを解除するよりもはるかに簡単です。また、データシート ビューや連続フォームをバインドなしで使用することさえできません。グリッド スタイルのビューで本当にバインドを解除したい場合は、10tec の iGrid などの ActiveX グリッド コントロール、またはレコードをフェッチするために必要な時間があるため、通常はより多くのオーバーヘッドを持つ MS リスト ビュー コントロールを使用する必要があります。グリッド コントロールにデータを入力するために必要な追加の時間。バインドされていないフォームには、フォームを ADO レコードセットにバインドするよりもパフォーマンスが向上するとは思えません。また、作成した ADO レコードセットを使用する必要がある場合でも、ADO レコードセットを使用できない種類のデータ ストアは実際にはありません。
これは非常に単純化していますが、MS Access での主なパフォーマンスの向上は、データ ストアのパフォーマンスを最大化し (通常は SQL Server に移行することを意味します)、読み込んでユーザーに提示するデータ量を慎重に管理することから得られます。後者を行う最も簡単な方法は ADO を使用することですが、DAO/ODBC を使用することもできます。ODBC には、遅延読み込みと呼ばれる ADO よりも優れた点が 1 つあります。データシート フォームまたは連続サブフォームを非常に大きなテーブル/DAO レコードセットにバインドでき、スクロールすると各レコードが読み込まれます。これは私があまり好きではない機能であり、スクロール バーを離すまでレコードが表示されないため、ユーザーから不満を言われましたが、最も優れている機能の 1 つであると言わざるを得ません。大量のデータ (> 50,000 レコード) を処理する効率的な方法。
UtterAccess Wiki には、DAO と ADO の長所と短所を詳しく説明したかなり広範な記事があります(この記事は削除されており、それを表示する唯一の方法は、当時の履歴を見ることです。差分/比較の下にスクロールします)。また、AccessExperts.com には、Juan Soto によって書かれたバインドされていないフォームに関する別のすばらしい記事があります。