考えられる問題：
1つの同時編集
問題のレコードが編集中の形式で開かれていることが原因である可能性があります。編集セッション中にプログラムでレコードを変更してからフォームを閉じようとすると（したがって、レコードを保存しようとすると）、accessは、レコードが他の誰かによって変更されたことを示します（もちろん、あなたですが、Accessは知りません。
プログラムでレコードを変更する前に、フォームを保存してください。
フォーム内：
'This saves the form's current record
Me.Dirty = False
'Now, make changes to the record programmatically
2主キーまたはタイムスタンプがありません
SQL-Serverテーブルに主キーとタイムスタンプ列があることを確認してください。
タイムスタンプ列は、レコードが最後に選択されてから編集されたかどうかをAccessが判断するのに役立ちます。タイムスタンプが利用できない場合、Accessはすべてのフィールドを検査することによってこれを行います。タイムスタンプ列がない場合、これはnullエントリではうまく機能しない可能性があります（3ヌルビットの問題を参照） 。
タイムスタンプには、実際には時間ではなく行のバージョン番号が格納されます。
タイムスタンプ列を追加した後、Accessでテーブルリンクを更新することを忘れないでください。そうしないと、Accessはそれを認識しません。 （注：Microsoftのアップサイジングウィザードは、AccessテーブルをSQL-Serverテーブルに変換するときにタイムスタンプ列を作成します。）
3つのヌルビットの問題
@ AlbertD.Kallalによると、これはここで説明されているnullビットの問題である可能性があります： KB280730
（WayBackMachineの最後のスナップショット、元の記事は削除されました）。ビットフィールドを使用している場合は、デフォルト値を0に設定します 以前に入力したNULLを0に置き換えます 。私は通常、BIT DEFAULT 0 NOT NULLを使用します ブールフィールドの場合は、ブールの概念に最も近いためです。
KBの記事には、*。mdbの代わりに*.adpを使用するように書かれています。ただし、 Microsoftは、Access2013でAccessData Projects（ADP）のサポートを終了しました 。