<HOME  <お願い事項   <Access2002 TOP   <Access2000 TOP   <サイト内検索
 Access97データベース工作室>郵便番号の検索
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15



これでオッケーのはず。さて、じゃ、フォームを・・・。

わーん。なんでー???まっさらだー・・・。という方、いらっしゃいます?


さっきのクエリー、もう一度見てみましょう。このクエリー、データシートビューに切り替えてみてください。

いつも、クエリーを開くと、一件もデータがなくても、白い行、一行だけ出て来てませんでした?
ないですねぇ。移動ボタンの[新規レコードへ移動]ボタンも、なんかクリックできなくなってると思いません?

だから、上のフォームは「レコードが一件もないし、新規に入力もできない状態」だったんですね。


じゃ、試しに、このフォームのレコードソースを、Q_郵便に変更してみましょう。
フィールド名などは全部クエリー1と同じだし、変えても問題ないと思います。

そうすると、いちおう1件目の「北海道中央区」のレコードが表示されてますけど、まあ、のっぺらぼうではなくなりますよね。

じゃあ、フォームを開いたときはQ_郵便を基にしてて、検索条件を入力したらクエリー1を基にする、みたいな感じにしてみましょうか。


[郵便番号を入力する]のテキストボックスの「更新後処理」というところで、ちょっとしたサーカスをします。

よく出てきますよね。「更新後処理」って。
テキストボックスになんか入力してEnterキーを押した後、とか、コンボボックスからなんか値を選んだ後、とかに動くマクロかコードを指定するんですね。

で、こんなコードを書きます。

Private Sub テキスト2_AfterUpdate()

Me.RecordSource = "クエリー1"

End Sub

Meはいいですよね。で、次にすぐピリオドがあるので、これでフォーム全体のプロパティであることをあらわしてます。
その中の「レコードソース」っていうプロパティに、クエリー1っていう文字を代入する、っていう意味ですね。ダブルコーテーションで囲まないと、クエリー1っていう単語として扱ってくれないので、注意しましょう。

すると、「フォームを開くときはQ_郵便を基にしてて、14万件すべてのレコードのうちの1件めが表示されるけど、郵便番号をなんか入力してEnterキーを押すと、フォームが基にしている情報源がQ_郵便からクエリー1に変って、検索結果が表示される」っていう形になります。

まあ、郵便番号を14万件、北海道からずーっと1件ずつ眺めて探す人はいないと思いますんで、あんまりいいかたちじゃないですけど、こういうテクニックって、どこかでお役に立つんじゃないかと思います。うまいタイミングさえつかめれば(今回は郵便番号を入力した後、ですね)、フォームが基にするレコードソースだって、ちょこちょこ入れ替えできるんです。


では、どうして「新規入力や更新のできない状態のクエリー」なんて、できるんでしょう。

もとにしているQ_郵便を見てみましょう。ちゃんとデータ出てますけども・・・。

あれー・・・このクエリーもやっぱり、新規入力ができない状態になってる・・・みたいですね。なんでかな・・・。

まあ、このクエリー自体は、新規に入力をする必要のないクエリーですし、フォームの方のデザインを何とかすればどうってことないんですけどね。

これにはいろいろな理由があるんです。でも、共通して言えることは、

クエリーが「俺って新規入力や更新したら、やばいクエリーだよな」と自己判断しているということです。

1)テーブルを10個も20個も組み合わせるようなクエリーで、結合の仕方が複雑すぎる場合
2)集計したりグループ化したりして、もとのテーブルと明細の単位が異なるクエリーの場合
3)主キーや重複しないインデックスを持たないテーブル同士の場合

他にも考えられるかもしれませんが・・・とにかくクエリーはかなり用心深いです。


下のふたつの表を見比べてみてください。

分類コード 分類名
01 イヌ
02 ネコ
02 さる
 
分類コード おなまえ おりこう度
01 ステファニー A
01 エルシー AA
02 ジュディ B
02 マリアン A
01 ライオネル BB

左の分類表を見ると、02はネコなのかさるなのか、わからんですね。
分類コードが主キーになっていれば、コードが重複することなんてありえないんで、こんなことにはならないはずなんですが・・・。

で、右の表と組み合わせて、それぞれ分類がなんであるか見たとき、ジュディはネコなのかさるなのか、本人に聞いてみないとこの表ではわからないですよねえ。

もし、このふたつの表をテーブルに見立て、組み合わせてクエリーを作るとしたら、ジュディとマリアンは、ネコだかさるだかわからず、すごくいいかげんな出力結果になっちゃうと思いません?

そうなると、マリアンの情報は、ネコの場合とさるの場合と、2レコード出てきちゃうんですよね。
と、そのデータシートビューから、マリアンの成績をAからAAに書き換えようかなーと思ったら、いったいネコのマリアンとさるのマリアンと、どっちのレコード書き換えたらいいんでしょう。
両方??ブブー。いつからそんないいかげんなことをいう人になったとですかっ!

ふたつのテーブルを結合するとき、どちらか一方の基準にする方のテーブル(この場合は左のブルーの方のテーブルでしょうか)に、主キーとなり得るフィールドが存在しない場合、クエリーは用心して、クエリーの結果を表示はするけどここから更新とか追加はなしね、という状況になるんです。
ね、よく考えてみると、賢明な措置でしょ?

主キーというものの意味合いや存在は、非常に分かりにくいですけれど、ふたつのテーブルを結び付けるとき、「このフィールドは主キーだから、ダブって入力されたりってことは絶対ありえないから、安心してくれたまえ」と、クエリーを安心させるひとつの判断材料になってるわけです。

なんか面倒くさいなーって思われるかもわかりませんね。確かにめんどうです。
表計算ソフトならこんなめんどくさいことはいっさい考えないで表を作ることができますよねぇ。

でも、マリアンがネコかさるかわかんなくなっちゃうような表は困る、っていうのは、おわかりいただけますよね。
めんどうですけど、こういう矛盾が生じないようにデータ管理をするために、表計算ソフトじゃなくてAccessを使うんだ、と思ってください。
この部分をあいまいにするなら、Access使う意味、あんまりないと思います。


ちょっと実験です。

[Q_郵便]の中で、まず最初に[都道府県テーブル]と[市区町村テーブル]が結びついてますよね。[都道府県番号]で。
つまりこのふたつのテーブル同士がクエリーで結びついたとき、このクエリーが新規入力&更新を可能にするか否かは、[都道府県テーブル]の中で[都道府県番号]が主キーになってるかどうか、こっちのテーブルは絶対値が重複してないよ、ということをクエリーに見を持って証明できるかどうか、ということにあります。

でも、外部から取ってきたデータとか、変換したデータって、主キーもくそもなくて、結構いいかげんだったりするんですよね。
今、主キー、ないですよね。

これを[都道府県番号]を主キーにすると、このテーブルは[都道府県番号]がダブらないテーブルという証明になります。
[都道府県テーブル]が1に対して、[市区町村テーブル]の方が複数あろうが一件だけであろうが、クエリーが迷うことはないわけですね。

 

同じように、今度は右側。[市区町村テーブル]と[地区テーブル]は[市区番号]で結びついてます。
[市区町村テーブル]の方で、このフィールドが主キーになっていれば、クエリーも納得するはずです。

主キーを設定して、保存してみてください。


さて。今度はどうでしょう。

どうやら、書き換えができる状態になったようですね。不思議ですよねぇ。
でも、とっても大切なことなんですよ。
テーブル同士が矛盾なく結びつくさま。それを大切にしながら、やっぱりテーブルから丁寧に作っていきましょう。

これでもう、[クエリー1]も更新可能なクエリーに生まれ変わったはずです。


ん・・・今、わたくしひとつ気づいたことがございます。
たしか、一番最初に作った[郵便テーブル]の中身は、140537レコードだったはず・・・。
[地区テーブル]もたしか、140537レコードだったと思った・・・。
でも、上のクエリーの結合結果は、140534レコード。。。3件少ないじゃないですか。なんで?なんで?