私は adOpenDynamic を使用しており、CursorLocation はデフォルトで Server (V6) に設定されており、プログラムはアクセスと SQL Server の両方で動作します。ここで、-1 を返す recordCount に問題があります。私は次の解決策を見つけました：
CursorLocation を Server から client に変更するか、CursorLocation を Client のままにし、adOpenDynamic を adOpenStatic または adOpenKeyset に変更します。Dynamic と Keyset の類似性に基づいて、adOpenKeySet で変更した方がよいようです。
これは私の質問です。adOpenDynamic を維持して CursorLocation を Client に変更するか、Server を維持して adOpenDynamic を KeySet に変更する方が良いと思いますか?
ありがとうございました。
答えはイエスとノーです。
これらのさまざまなオプションが存在するのには理由がありますが、そのほとんどは機能とパフォーマンスに帰着します。
カーソル位置をサーバーに設定すると、一度にすべてのデータを「取得」することはできません。一部は戻ってきますが、残りはリクエストするまでサーバーに残ります。レコードセット内の次のレコードに移動すると、その要求が実行されます。これは通常、非常に大きなレコードセットがある場合にパフォーマンスが向上します。これは、すべてのデータがネットワーク経由で設定される前に、アプリがデータの使用を開始できるためです。これは、往復の「会話」が多数発生するため、ネットワークの使用にはあまり適していません。また、レコードセットを閉じるまでサーバー リソースを消費するため、サーバーにとっても好ましくありません。
クライアント カーソルを使用すると、すべてのデータがネットワーク上で可能な限り迅速に渡されますが、すべてのデータがクライアントに渡されるまでアプリはデータを使用できません。大規模なレコードセットでは、これに時間がかかる場合があり、結果としてアプリの動作が遅くなる可能性があります。クライアント レコードセットは、サーバーとネットワークには適していますが、遅延のためにクライアントにとっては難しくなります。
このように考えてください.... グリッドに表示したいデータがたくさんあるとします。サーバー カーソルを使用すると、データの最初の「ページ」を表示できます。次に、ユーザーがグリッドを下にスクロールすると、次の 20 行を取得して表示します。そのため、ユーザーがスクロールするたびに、わずかなラグが発生します (おそらく目立たない程度です)。クライアント カーソルでは、ユーザーが何かを行う前に、すべてのデータをグリッドにロードする必要があります。
私のアプリでは、データベースから必要なデータのみを返すことに細心の注意を払っています (列と行を制限しています)。ほとんどの場合、adOpenStatic を使用してクライアント側のカーソルを使用します。基本的には、データベースを呼び出してデータを取得し、できるだけ早くレコードセットを閉じます。次に、挿入、更新、および削除に対して個別の SQL ステートメントを発行します。
あなたへの私の最善のアドバイスは、最初にこれらすべてのオプションがあなたのために何をするかを学び、次に正しいものを使うことです. これはおそらく、必要な機能に応じて、アプリ全体でいくつかのメソッドを使用することになることを意味します。