スタッフの日記

あるMS-Accessのシステムのバージョンアップで、「あり」と「なし」を値とする項目が必要になったので、テーブルに当該の項目をYes/No型として追加しました。

そして、その値を設定するフォームを作成して動作確認したところ、・・・

コンピュータは 何かやってるんですが、フォーム上の表示では空白にしかならないんです。

下図は、この事象の調査のためにいろいろやってみたものです。「対象の有無」とあるコンボボックスがその項目だと思ってください。

ここでコンボボックスをクリックしてドロップダウンさせると、「あり」と「なし」が表示されます。

ここで、「あり」を選択しても、コンボボックスの表示は空白のままなんです。

これが「不思議なこと」とタイトルで言っていることです。

よくよく目を凝らして、フォームの左端のレコードセレクタを見ると、鉛筆マークになっている。つまり、何かが変わったということです。

そこで、テーブルの内容がどう変わったのか確認してみました。

なんと！、値が「－１」になってるんです。

「True」と「False」でも、「Yes」と「No」でもなく、「－１」と「０」なんですね。

この項目のルックアップを確認すると、「True」と「False」にしていました。

そこで、「－１」と「０」に直しました。

そして、テーブルの内容を初期値に戻してフォームを表示してみると、下図の通り。目的通りの表示です。

コンボボックスをドロップダウンしたときの表示はちゃんと現在の値に対応したところ：「なし」が選択され、「あり」を選択の結果も目的通りの結果でした。

どうも、コンボボックスの値集合ソースでは、すべて文字列として処理されるみたいです。だから「True」と書くと「"True"」という文字列として処理されてしまう。そして、テーブル上の「－１」とは一致しないので空白表示になるようです。ところが、「あり」を選択して「"True"」を設定させようとすると、「"True"」を「－１」に変換してくれるわけです。「Yes」でも「－１」に変換してくれますが、「はい」だとエラーになります。この中途半端さが、いかにもMS-Accessらしいですね。

という訳で、「Yes/No型の項目をコンボボックスで処理するときは、『－１』と『０』にすべし」と覚えておこう。

最近は、メールでの文書のやり取りが多くなり、指摘事項もメールにいちいち引用先を記して書くことは面倒になってきました。そんな時、Acrobat Readerの注釈機能とFDFというファイルがあることを知ったので、紹介したいと思います。

たとえば、下図のように使います。

一点鎖線の左と右では別の人だと思ってください。

まず、Aさんが文書（PDFファイル）を作成します。

それを受取ったBさんは、文書に「注釈」（私の脳内では「いちゃもん」と変換されます）を付けたくなったとします。

ここでまず、Acrobat Readerの注釈機能が登場します。PDFファイルのどの部分の注釈かも、すぐわかるようになっています。

次に出てくるのが、FDFファイルです。Acrobat Readerの操作で、注釈情報のみを出力することができます。

Bさんは、FDFファイルをAさんに送ります。

Aさんは、送られたFDFファイルと、元のPDFファイルとを読込んで、どんな注釈がつけられたかを見ることができます。

図には書きませんでしたが、Aさんは、注釈に対する返信を付けてFDFファイルにしてBさんに送り返すこともできますし、さらに別の人に送って…ということもできます。そして、こうしたやり取りが、ぐちゃぐちゃにならず、FDFファイルとして形に残し、管理できるということも重要です。

Acrobat Readerの、具体的な操作については、下記などを参照してください。これは、少し古いAcrobat Reader Xについてなので、その後のバージョンとは少し違いますが、参考にはなるでしょう。

https://helpx.adobe.com/jp/acrobat/kb/4561.html

はじめに　

  ある入力画面フォームで登録ボタンを用意、クリックイベントの処理（イベントプロシージャ）でデータベースに登録する処理を割り当てました。運用になってからしばらくは順調に動作していましたが、複数の担当者の内、ある人が操作した時に、データが２重登録されるケースが出現。
　
　
原因について

　どうやら、その担当者は登録ボタンをダブルクリックしていて、クリックイベント処理が２回走ってしまったことが原因らしい。
改めてACCESSのヘルプを見直すと、
　
　Form.DblClick イベント (Access)
　https://msdn.microsoft.com/ja-jp/vba/access-vba/articles/form-dblclick-event-access
　
　■マウス イベントを受け取るオブジェクトに対しては、次の順序でイベントが発生。

　　　MouseDown ⇒ MouseUp ⇒ Click ⇒ DblClick ⇒ MouseUp　

　■コマンド ボタンをダブルクリックすると、次の順序でイベントが発生。

　　　MouseDown ⇒ MouseUp ⇒ Click ⇒ DblClick ⇒ MouseUp ⇒ Click
　
　との事。
　
　今回のケースは、コマンドボタンをDblClickした場合なので、Clickイベントが２回発生した。
　そもそも、DblClickの時にClickイベントが発生する事など、全く考えていなかったので、この仕様には驚いています。ただ、今回の事を知って改めて考えると、パソコンの設定によってDblClickとClickの判断は難しい場合があるのだと思えば、なんとなく納得しています。
　

対応方法

２回目のClickイベントを無効にする次の方法で対応します。　
DblClickイベントプロシージャの引数に「Cancel」があるので、この引数にtrueを設定して終了すれば、以降のClickイベントは発生しません。
　
　例)
　
　Private sub XXXボタン_DblClick(Cancel As Integer)
　　　Cancel = true
　End sub
　
おわりに

　入力画面を設計する際、ＧＵＩの観点からなるべく入力を簡単にできるよう考えます。
例えば、テキストボックスをダブルクリックするとデフォルトの値が設定されるようにするとか。
結果として、クリック操作とダブルクリック操作が混在する画面の操作性の良し悪しは、
判断が分かれるところですが、今回のようなケースでうっかり操作による誤動作の対応はしておきましょう。

　なお、Accessのヘルプには、
　”一般的には、コマンドボタンをダブルクリックしない事をお勧めします”
　とありました。

１．事象
　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値が設定された状態になり、システム側で強制的に値を設定しようとして、結果的にその動作が競合となりエラーになってしまったのでしょうか。
（根拠なし、想像です）

以上