スモールビジネスのIT日誌

• (2009-03-17 10:24:33)

郵便番号からの住所自動入力プログラムを掛けている限り、住所記入欄で番地の記入忘れは撲滅できない。どっちも外せない。

-------------------------------

お客様の住所記入欄で番地の記入忘れがたまに発生する。自宅の番地をなぜ書き忘れるのか？興味深い問題である。この検証と対策はまた別の機会に行うとして目先の対策として当社でチェックし、発送前に連絡するようにしている。

しかし、ここが悩みどころ。人の目でチェックするので必ず漏れるものがでてくる。先日お客様から「なかなか来ないので明細を確認したら番地が抜けていました。再送よろしくお願いします！」というメールが来る。この種のトラブルはなんとか事前に回避したいものだ。

システムで番地忘れのフィルタリングしたいのだが、なかなかよいアイデアがでない。思いつくことは下記の不完全な条件：

・通常住所は番地、すなわち数字で終わる

・数字で終わらない住所は部屋や階を示す「号」「室」「F」「階」「方」などがある

とりあえずこれらの条件に合わない住所のレコードをピックアップすれば人の目での検査も検品確率の精度も上がるだろう。またまた受注データベースのACCESSを眺める。クエリで上記条件をセットすることにしたが、やり方がわからずクエリをしばらく眺めていた。

思うにACCESSのクエリはMicrosoft社の技術者が「SQL文をビジュアルに図式化したらどんな図になるか」というテーマのもので作られたのだろう。この図表が簡単にSQL文に落とせる理由はそこにあるのかも。

クエリ図表の骨格フレームワークになるものはレコードの各フィールド。図表(テーブル)を引いて横方向に必要なフィールドを入れていき、各フィールドの選択条件や並べ替え条件を記入できる欄を下に追加するというテーブルになっている。

選択条件や並べ替え条件は横方向のフィールドに対して「And(かつ)」結合となっている。選択条件を「Or(または)」結合したい場合は選択条件の行を下に追加していく。並べ替え条件が複数ある場合、ソートの優先順位は左側優先となっているようだ。

住所フィールドの「最後の1字」を拾い出して、それが数字かどうか、また「室」や「号」や「F」などでないかという判別にはちゃんとMicrosoft社から関数が提供されていた。本当に感謝したい。

「最後の1字」を判定する計算式をどの欄に入れてよいのか、「とっさにわからなかった」ということが今日のテーマ。

反射的に「住所フィールド」の下の選択条件欄に入れようとした。この選択条件は住所フィールドそのものに対して成されるので、できないことはないかもしれない。入れてみた。既存のフィールドに何かの関数を噛ませることは認められないようだ。しかし、自動的に関数に住所フィールドを通して生成された「新しいフィールド」がテーブルの横方向に追加された。驚くべき賢さ。

おそらくやったことはルール外ながらよく間違われるのだろう。その対策としてMicrosoftの粋な計らいの結果だろう。今となってみれば、関数に住所フィールドを通して生成された「新しいフィールド」をダイナミックに一つ追加するという考え方の方がはるかにすっきりしている。ダイナミックで仮想的に新しいフィールドを追加できることがクエリの醍醐味か。Jetエンジンのコアな部分ってこの辺かもしれない。

というわけで新しいフィールドを2カラム追加：

・新フィールド1：式1: IsNumeric(Right([住所1],1))

選択条件：False

・新フィールド1：式2: Right([住所1],1)

選択条件：Not Like "室" And Not Like "号" And Not Like "F" And Not Like "階" And Not Like "方"