sql-server上にリンクされた（odbc）テーブルを持つAccess-dbがあります。特定の行の1つの列にまれな問題が発生する場合があります。つまり、タイプmemoのフィールドをこれ以上変更することはできません。この特定の行の他の列の変更は、通常どおり保存されます。error-msgは次のようになります。別のアプリケーションが行を変更したため、更新がキャンセルされました。
理由は何でしょうか、この行動を防ぐために何ができるでしょうか？
ピースアイス
アップデート：
mdbは間違いなく破損していません。内部にはodbc-connectionsのみがあり、読み取り専用モードで使用します。問題は、それぞれsql-serverのjet-engineとodbc-driverの間にあるはずです。それが私が思うことです。
平和
氷
データがJet/ACEバックエンドに保存されている場合は、メモポインタが破損している可能性があります。データはSQLServerにあり、ODBCを介してアクセスされるため、それが答えになることはありません。ただし、Jet / ACEバックエンドで問題が発生している他の人がこのディスカッションに参加する可能性があるため、以下が役立つ場合があります。
Jet / ACEテーブルでは、メモデータは他のフィールドとインラインで保存されません。代わりに、データは他の場所の個別のデータページに格納され、インラインで格納されるのは最初の外部データページへのポインタだけです。そのポインタは破損しやすく、データが失われる原因となることがよくあります。
Tony Toewsからのいくつかのリンク（これの最良の情報源）：
その2つ目では、3197を検索します。これは、発生している問題のエラー番号である可能性があります。トラブルシューティングの方法を説明するリンクがあります。
修正したら、メモフィールドが破損するリスクを最小限に抑えるために、データテーブルの再構築を検討する必要があります。
Accessを使用していないことは承知していますが、Accessフォームの場合、1つの解決策は、バインドされたメモフィールドを避け、代わりにバインドされていないテキストボックスで編集することです。AccessフォームのOnCurrentイベントでは、メモデータをフォームのフィールドコレクションからバインドされていないテキストボックスにコピーし、テキストボックスのAfterUpdateイベントで、フォームの基になるレコードセットに保存します。
アクセスの有無にかかわらず、すべてのアプリケーションで、メモを別のテーブルに配置すると、メモフィールドポインタが残りのデータから分離されます。メモが1つある場合は、1：1のテーブルにすることができ、複数のメモがある場合は、1：Nがあり、メモテーブルにはメモの種類を示すフィールドが必要です。この構造では、破損したポインタを修正するためにメインレコードを削除して再作成する必要はありません。必要なのは、メモテーブルの破損したレコードを削除することだけです。