スタッフの日記

１．事象
　ACCESSの単票フォームのレコードソースとしてSQLServerのテーブルを指定している。「Microsoft SQL Server Manager」を使い、このテーブルに次のような列を追加して、フォームで更新操作をしたらエラーが発生。

追加した列：　Ａ項目 　bit型 　null可

エラーメッセージ：データの競合

“このレコードは他のユーザーによって変更されています。[レコードの保存]を選択すると、他のユーザーによる変更を無視し、自分が行った変更を反映します。[クリップボードにコピー]を選択すると、変更したデータはクリップボードコピーされ、他のユーザによる変更が反映されます。必要に応じて、クリップボードのデータを張り付け、自分が変更したデータに戻すこともできます。”

なお、このエラーが出た時、もちろん操作をしているのは、自分だけです。

２．対処と原因

[対処]

　A項目 bit型 null可 　　→ 　　Ａ項目 bit型 null不可 (必須項目、初期値:0）

　nullを許容しない、必須項目とする事でエラーを回避しました。

[原因]
　はっきりした原因は不明。ネットで検索した対処方法によると、どうやら、ACCESSでリンクする場合、bit型のようなBOOL属性の項目は、必須項目にしないとダメなようです。裏でどんな動きをして、今回のようなエラーが発生してしまうのか。

　以下、思った事。

　bit型は、ACCESSのデータ型ではYes/No型になります。ACCESSのフォームにおいて、チェックボックスの値を格納する時のデータ型として、よく利用します。なので、データはYESかNOかの２択で、nullはありません。今回、該当のテーブルは、元々、ACCESSのmdbのテーブルで、ACCESSのアップサイジング機能を利用してSQLServerのテーブルに変換したテーブルです。追加した列のプロパティは、そのテーブルにおいて既存のbit型列にならって設定しました。既存のbit型列は"null可"になっていました。同じように設定して、結果、エラーが起きました。改めて既存のbit型列のプロパティを見直したところ、拡張プロパティが設定されていたので、全て同じように設定しました。

例えば、次の拡張プロパティ

AllowZeroLength : False
AppendOnly: False
Attributes:1
CollatingOrder:1041
DataUpdatable:False
MS_Format:Yes/No
etc..(拡張プロパティは18項目あり)

　これらを設定しても、状況は変わりませんでした。さて、なんだろう。

　アップサイジング機能で変換されたbit型の列は、nullを許容する設定でしたが、既存レコードには値が全て設定されていました。後で、「Microsoft SQL Server Manager」で追加したbit型の列は、既存レコードにnull値が設定された状態になり、システム側で強制的に値を設定しようとして、結果的にその動作が競合となりエラーになってしまったのでしょうか。
（根拠なし、想像です）

以上