ここでストローをつかみます... 私はいくつかの 2003 スタイルの Access データベース (.MDB) を使用する VB6 デスクトップ システムで作業しています。最近、最初の関数を VB6 から VB.NET に変更しましたが、まだ Access データベースを使用しています。これは単なる変換ではなく、機能を追加して書き直したものです。これはまだかなり単純な機能であり、少量のデータベースを使用しています。私たちには、さまざまな機械の品質を持つ 1400 の小規模企業のお客様がいます。ほとんどのお客様は、新しい画面と機能に満足しています。これらの顧客のごく一部は、datagridview のロードが極端に遅くなった経験があります。カスタマー サービスによると、1) マシンには少なくとも 1 GB の RAM があり、2) 再起動すると常に問題が解決します。
マシンの速度を大幅に低下させるアプリを作成しましたが、少数の顧客よりも優れた動作をします。また、Access データベースがこのアプリケーションによって破棄されたことはありません。
助言がありますか？
ありがとう！！
アクセス データベースの更新中に再起動すると、データベースが破棄される可能性があります。
何が起こっているのかをよりよく理解するには、もう少し情報が必要です。問題が発生しているワークステーションについて、情報を収集する必要があります。タスク マネージャーを使用すると、次の情報を取得できます。
XP と Vista の両方でコマンド ライン ツール「SYSTEMINFO」を使用して、合計メモリと使用可能メモリを取得することもできます。利用可能なものがほとんどなく、XP でコミットされた合計が物理的な合計よりも大きい場合は、スワッピングが発生している可能性が高く、メモリ不足 (またはメモリ リーク) が原因で速度が低下しています。
肝心なのは、より多くの情報が必要だということです。ワークステーション上の別のアプリが問題を引き起こしている可能性があります。Notes 5.0 では、ウィンドウの大部分が別のウィンドウで覆われているときに新しいメール メッセージを受信すると、Notes の CPU 使用率が 100% になるという問題がありました。これにより、アプリの実行が遅くなり、ワークステーションでタスク モニターを見ていなければ、Notes が問題を引き起こしているとは決して推測できませんでした。問題は常に別のプログラム (フォアグラウンドにあるプログラム) で呼び出されました。Access は、何もしていないように見えても、さまざまなモードで 100% の CPU を使用することもできます。
できるだけ多くの情報を収集してください。何らかの情報を収集する vbscript またはプログラムを作成して、問題を抱えている人が再起動する前にそれを実行して情報を収集できるようにすることをお勧めします。
以下を実行するバッチ ファイルは、かなりの情報を提供します。
@echo off
SystemInfo >c:\systeminfo.log
tasklist /v >>c:\systeminfo.log
同様の経験がありますが、ほとんどの場合、ウイルス対策が原因です。彼らは非常に頻繁にファイルをチェックします（ファイルへのアクセスごとにいくつかのアンチバイアがあります）。
いいえ、VB.Net は Access とうまく連携します。SHARED 環境はアクセスを破棄します。
再起動すると問題が解決するので、接続を適切に閉じていることを確認します。
私には大きなメモリリークのように聞こえます。
一部の顧客は、他の顧客よりも長くアプリケーションを実行したままにし、より大きな打撃を受けるでしょう。
少数以上の同時ユーザーがいる場所で Access を使用すると、必然的に苦痛になります。