FoxPro DBFインデックスの破損
私たちは、BESTと呼ばれるかなり古い会計システムを通じて、ロシアや他のCIS諸国で非常に人気のあるアプリケーションを実行しています。それはすべてFoxPro（Visual Foxproではない）DBF/CDXテーブルに基づいて構築されています。オープンですが、他のソフトウェアとやり取りするためのAPIがありません。したがって、テーブルとデータへの直接アクセスを使用する必要があります。
私たちは、Sybase Advantage Database Server（ADS Internet Connector）を使用して、オンラインストアをBESTに接続しています。開発、テスト、および最初の3か月間の実行中に、すべてが順調でした。しかし、ほぼ半年前に、インデックス破損エラーが発生し始めました。ネットワークケーブルとNICの交換、HDDを搭載したRAIDコントローラー、メモリ、Windowsサーバーの再インストールなど、ほぼすべてを試しました。テーブルとインデックスを再構築し、ログを調べましたが、すべてが役に立ちません。 2日に1回、インデックス破損エラーが発生するため、サーバーを停止し、テーブルのインデックスを再作成して再起動する必要があります。会社全体が10分間待機しています。
注文とその内容の2つのテーブルでのみ問題があります。使用されている他のすべての300のテーブルが害を受けることはありません。ケースをより困難にしているもう1つの問題は、問題が即時ではないということです。インデックスファイルが壊れている場合-表示されません。ユーザーの1人が新しいセッションBESTを開始するか、クライアントが注文するまで、ユーザーは作業を続けます。それが起こる瞬間を捕まえることは不可能です。
現在、ADSを非難しています。そのような問題とそのADSでの解決策について誰かが知っていますか？私は答えを求めてすべてのインターネットをサーフィンしましたが、何も見つかりませんでした。
ありがとうございます。
CDXインデックスで発生する可能性のある破損には、論理的な破損と物理的な破損の2つの基本的な種類があります。しばらく検出されないというOPの説明に基づいて、論理的な破損のように聞こえます。論理的な破損の一般的なタイプは、レコードにキーが存在しないか、存在してもキーの値が正しくない場合です。 CDXインデックスの物理的な破損は、通常、単に無効なインデックスページ（たとえば、キーカウントと実際のキーの不一致）や、存在しない他のページへのポインターがあることで明らかになります。
物理的に破損しているページを処理しようとすると、アプリケーションがエラーを生成することが多いため、通常、物理的な破損はより早く検出されます。エラーが報告されずに論理的に破損したインデックスを使用することは非常に可能であるため、論理的な破損が長期間検出されない可能性があります（たとえば、シーク操作でキーが見つからないことは「通常の」状況です）。
OPで説明されている論理的な破損であると想定すると、1つの考えられる理由は、Advantage Database Serverがデータを共有しているFoxProアプリケーションとは異なる照合を使用している場合です。古いスタイルのCDXインデックスには、照合を定義する情報が含まれていません。これが当てはまるかどうかを確認するために使用できる簡単なチェックの1つは、 checkindex ユーティリティをダウンロードすることです。これは、テーブルをスキャンして、キーとレコードが互いに一致していることを確認する単純なユーティリティです。 FoxProでテーブルのインデックスを再作成する場合は、このユーティリティ（Advantageを使用）を実行し、同じ照合を使用しているかどうかを確認できます。 照合順序はこちら に関する詳細情報。
インデックスの破損に関する私の経験では、FoxProアプリケーションを開いたまま日中にリセットするのは通常、ユーザーのマシンです。ユーザーにこれを行うかどうかを尋ねます。また、自動化された夜間再インデックスプログラムを作成することもできます。