スタッフの日記

ACCESSのフォームでSQLServerのテーブルを更新したら『データの競合』エラーが発生

2017年2月19日(staff)

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

追加した列: A項目  bit型  null可

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

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

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

2.対処と原因

[対処]

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

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

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

 以下、思った事。

 bit型は、ACCESSのデータ型ではYes/No型になります。ACCESSのフォームにおいて、チェックボックスの値を格納する時のデータ型として、よく利用します。なので、データはYESかNOかの2択で、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値が設定された状態になり、システム側で強制的に値を設定しようとして、結果的にその動作が競合となりエラーになってしまったのでしょうか。
(根拠なし、想像です)

以上

一覧表示 ▶︎ スタッフの日記, ブログ

Comments are currently closed.