現在、DAO を使用して VB6 を使用して MS Access DB に接続しています。2 番目のユーザーがデータベースに接続すると、速度が著しく低下します。
再現する手順は次のとおりです。
ソフトウェアにログインして、コンピューター A からデータベースを開く
ソフトウェアを介してデータベースにレコードを追加します (約 0.4 秒かかります)
2 番目のユーザーがソフトウェア (コンピューター B) にログインします。つまり、データベースが開き、今日のトランザクションが表示されますが、ユーザーは他に何もしません。
コンピューター A で、レコードを追加する操作を繰り返します。この操作には約 6 秒かかります。
詳細情報…</p>
コンピュータ B がソフトウェアからログアウトした後も、操作には約 6 秒かかります。
コンピューター A からアプリケーションを閉じて再度開くと、操作は実行にわずか 0.4 秒かかります!
どんな助けでも大歓迎です！
ありがとう！
それが MS Access の仕組みです。複数のユーザーをサポートし、複数のPCがアクセスできるようにファイル共有にDBを配置することをサポートしていますが、どちらもあまりうまくいきません. また、両方 (マルチユーザーとネットワーク経由でファイル共有) を行っている場合は、ご苦労をお察しします。
答えは、アップグレード ウィザードを実行して、これを MS SQL Server インスタンスに変換することです。この場合、Acess を置き換えるには、MS SQL Server Express エディションが適しています。Access にあるすべてのコードやレポートなどを引き続き保持できることに注意してください。移動する必要があるのはデータのみです。
違いを明確にするために、MS Access では、データベースからデータを読み取るときに、クエリを実行するために必要なすべてのデータがプログラムによってファイルから読み取られ、サーバー側の処理は行われません。そのデータがネットワーク上に存在する場合、そのデータはネットワークを介してプルされます。複数のユーザーがいる場合は、ロックのオーバーヘッドが追加されます。各ユーザーのプログラム/プロセスは、ファイル I/O を介して他のユーザーのプログラム/プロセスと効果的に対話します (ネットワーク化されたファイルにロック情報を書き込みます)。また、ネットワーク I/O がタイムアウトしたり、他の問題が発生したりすると、それらのファイルが破損する可能性があります。
SQL Server では、データ要求を管理し、必要なデータのみを返すのは SQL Server エンジンです。また、ロックを管理し、クライアントが切断されたか、クリーンアップのためにタイムアウトしたことを検出できるため、ネットワーク上の複数のユーザーによって引き起こされる問題が軽減されます。
新しいファイル サーバーの使用に移行したときに、VB3 / Jet DB 2.5 アプリケーションでこの問題が発生しました。
問題は「日和見ロック」です: http://support.microsoft.com/kb/296264?wa=wsignin1.0
アルバートはおそらく同じことを説明しています。サーバーは1つのクライアントにファイルの排他的アクセスを許可しますが、別のクライアントがアクセスすると、この排他的アクセスはそれらの間で「スラッシング」し、他のクライアントがアクセスできるようになる前に、oplockを持つクライアントがすべてのローカルキャッシュをサーバーにフラッシュするため、遅延が発生しますファイル。
これが、1 つのクライアントで良好なパフォーマンスが得られる理由でもある可能性があります。oplock を使用すると、すべてのデータをローカルにキャッシュできます。
また、クライアントの 1 つが停電したり、ネットワークから切断されたりすると、サーバーへのローカル キャッシュのフラッシュが中断される可能性があるため、厄介な破損が発生する可能性があります。
記事に従って、Windows 2000 および XPでこれを無効にすることができました (クライアント上で、すべてのクライアントにサービスを提供する必要があるため) が、Vista SP2 以降では不可能のようです。
Access / JetDB をマルチユーザー データベースとして使用しないというコメントは基本的に正しいです。特に上記の点を考慮すると、これは適切なアーキテクチャの選択ではありません。DAO は、廃止された VB6 でも廃止されたライブラリです。ADODB は VB6 に適した選択肢であり、アプリの作成方法に応じてデータベースの独立性をある程度確保できるはずです。
ご指摘のとおり、システム上の1人のユーザーで適切なパフォーマンスが得られるため、アプリケーションは本来、ネットワークを介して大量のデータを取得しているわけではなく、ここでネットワーク速度を非難することはできません。
実際に起こっているのは、Windowsファイル共有システムが単一ファイル共有モードから複数共有ファイルモードに切り替わっているということです。このファイルモードの切り替えにより、大幅な遅延が発生します。また、これは、2人目以上のユーザーがファイルのロックを把握して設定する必要があることも意味します。
アプリケーションの開始時にこの顕著な遅延を取り除くには、持続的接続と呼ばれるものを開きます。持続的接続とは、ネットワーク接続を常に開いたままにするものであるため、ファイル共有のために2つのファイルモードを切り替える際のこの大幅な遅延が解消されます。ここで、2人のユーザーのパフォーマンスは1人と同じである必要があることがわかります（1人のユーザーがアイドル状態で、ネットワーク負荷が増加していないと仮定します）。したがって、アプリケーションの起動時に、グローバル変数に対してバックエンドテーブルを開き、そのテーブルを常に開いたままにします。