Access + SQL サーバーを使用するのとは対照的に、既存の Access アプリケーションにある優れた設計に実際の変更はありません。
つまり、既存のアプリケーションを使用してデータ テーブルを SQL サーバーに移動し、引き続き既存の Access アプリケーションをフロント エンドとして使用することができます。
ここでは、SQL サーバーを使用しない「のみ」の Access と、Access + SQL サーバーを使用する場合に適用される実際のアドバイスはありません。つまり、SQL サーバーと連携するように Access アプリケーションを構築する方法を実際に変更する必要はありません。
Access のみのアプリケーションでスケーリングして適切に機能する優れた設計は、Access をフロント エンドとして使用し、SQL サーバーをバック エンドとして使用する場合にも、かなり適切に機能する傾向があります。
基本的なヒントは次のとおりです。
フォームを開くときは、フォームを起動する前にユーザーに尋ねてください。サーバーから大量のレコードをドラッグするフォームを起動し、ユーザーにアカウント番号など必要なものを尋ねるのは意味がありません。そのため、ユーザーにある種の検索を要求します。次のような画面を言います。
100万行のSQLサーバーにヒットした場合でも、上記はINSTANTです。上記では、Access から 100% リンクされたテーブルを使用しており、ここでは特別なトリックはありません。単純な SQL ステートメントがサブフォームに押し込まれているだけです。したがって、これは SQL サーバーへのリンク ビューです。
次に、ユーザーが行をクリックすると、WHERE 句 ("ID = " & me!id) を使用してフォームを起動するだけです。
この「where」句は、Access のバインドされたフォームやリンクされたテーブルや SQL サーバーでも正常に機能します。
レポート内の複雑なクエリ (クライアント側のフィルター リクエストを含む) にはビューを使用します。
さらにパフォーマンスを向上させるために、一部のレポートにパススルー クエリを採用することもできますが、ほとんどの場合、SQL 側でビューを作成し、Access からそれらにリンクすることはうまく機能し、最小限の作業です。
したがって、Access と SQL Server を使用してソフトウェアを開発する方法に実際の "変更" はありません。唯一の問題は、ユーザーが何を編集したいかを決定するまで、レコードをフォームにロードしないことを常に心に留めておくことです。このアプローチは、Access + SQL サーバーを使用する場合に適用されるだけでなく、ネットワーク負荷を軽減するために不要なレコードをフォームにプルする必要がない、またはプルしたくないファイル ベースの Access アプリケーションでも適用されます。
ほとんどの場合、OpenForm コマンドに付加された「単純な」where 句で十分です。
したがって、適切な Access 専用アプリケーションや Access + SQL サーバー アプリケーションの開発方法に「実際の」変更はありません。