予告通りに、フォームの作り方について書きたかったが、レポートの機能と被る所が多いと思ったので、今回はフォームとレポートについてカキコ。
アクセスのフォームやレポートは、デザイン的にはエクセルやワードのテキストボックスやVBの画面設計・印刷設計に近いものだ。
直接テーブルやクエリーをデータとして扱える点で簡単なのが特徴で、ウイザードを使うとある程度は使えるデータベースのフォームが簡単に作れる。
ちょっと凝ったものでもフォームのウイザードでは対応しているが、それを開いた時や閉じた時のタイミングで各種クエリーを実行したら、後で見てもデータの流れが掴み易い。データを編集したとして、そのデータのチェックをデータのフォームを閉じる時にやったり、キーを付け補足説明を読み込んだりするのをこの開いた時や、閉じた時にやると入力中の待ちは少なくてストレスなく使えるフォームになる。
どうしても必要な場合には、ボタンを押して更新とか追加や削除をする方がいいが、自動更新をやたらと使うなら変なタイミングで更新されたりして、制御が難しいかもだ。
他に、画面に出しているデータと画面の中に隠しデータとして持っているデータがあって、それを上手く使うことで新たにテーブルを開いたり、編集に使ったりしなくても途中計算や変換を簡単に出来るので、関数などでは複雑になる計算、わざわざテーブル作りたくない処理などの応用が利く。
例えば、表示されているデータの集計作業。これをテーブルに書きだして、集計クエリーで計算して、フォームに呼び出すというパターンが有ったとしよう。同様の計算結果を得るにはフォームの隠しデータに集計関数を入れて集計して、結果を表示にすると、テーブルやクエリーの更新タイミングを考慮しないくて済む簡便なフォームに出来る。一種の表計算を使っている様な見た目は簡単に出来るのだ。（作る場合も表計算のやり方と同じになるので、その点で簡単とは言えないが。。。）
そういったちょっとした計算作業等に、隠しデータはすごく向いている。
フォームに出来る操作のうち、入力以外の操作はレポート上でも一応は出来る。
見せるだけのパターンだとプレビューでレポートを見せるほうが、出力範囲を細かい調整なしに大きな範囲で取ったり出来るし、表示の大きさなどはその都度、自由に変えられるので、どっちがいいかは吟味して使うと使いやすいと思う。
先ほどレポートでは出来ないといった入力も例えば選択クエリーの一種であるパラメータクエリーを組み合わせると、その弱点を補える動作可能だ。
私の変わった使い方をしているレポートのパターンとしては、期首データのみパラメータクエリーで渡して、その後の計算と、元データはデータベース内の各種テーブル・クエリーから貰って表計算のような集計作業で当日の生産量と使用量を縦に算出し、翌日残を求めてというルーチンを一日毎で一ヶ月分を1つの表にしたものを作った。
これは、中間原料の日々の増減に使えたが、中間原料の生産量とその使用量の追っかけデータを並列に並べて同日の増減を求めて翌日の計算に繋いでいるだけなのだが、複数のデータを平行して見ないと作れないのでエクセルには難しいかと思いアクセスで作った。
生産量が増減する関係で、レポート出力を使うとデータの増減に合わせて表の行数が自動変動する関係で、意識しなくても綺麗な出力になる。
当然、計算もレポート上で出来るので、集計も楽に出来て見易い表になった。
他に、フォームではプルダウンメニューも、ウイザードでなら簡易テーブルをフォーム内に作る、データボックス。件数が限られている場合や、少数だが固定データが必要な場合に使いやすい。
隠すというと、テーブルやクエリーなどで隠して置いた方が都合がいい物。例えば、削除不可にしたい時や、開発中のみ必要なテーブルをテーブル作成クエリーで作った場合など、一旦作ってしまえば消してもいいが残しておくと参考資料になるような場合、プロパティの表示を隠すのチェックを入れると、簡単に隠すことが出来る。
他には、自分でSQLを空で書いても何とかなるが、ちょっと複雑でデザインモードなどを使ったら簡単に出来る場合、デザインモードで書いてからそれをSQLで開き直し、微妙な調整をした後（これが無ければ、言うことないソフトなのだが。。。）コピーして、モジュールやマクロに組み込む。その後、使ったクエリーの表示を消す。といった作業の流れでやると、後々見ても分かりやすいデータベースになる。モジュールのコメント欄に参照元クエリーなどを書き込んで置くと、更に分り易くなる。
早い話が、アクセスの自動作成のSQLはそのままでは使えないと言うこと。ちょっと便利だが、悪く言えば言葉を覚えたてのこどもにSQLを作らせているような基本機能のみで、癖が強くて使用者の用途とは違う動きに勘違いしているSQLコーディングを自信を持って作ってこられても困るのだ。
自動のフォームも、無駄に罫線が入ったり表示位置の見栄えが悪かったり、結局は修正が入らないと使えないと思う。
一通りはフォームやレポートを手動で作る事も出来ないと、この自動作成機能は使いこなし出来ないかと思う。
フォームとレポートの話では、さすがにアクセス専用の説明に偏ってしまうが、それ以外のデータベースでのやり方は守備範囲や私の少ない知識では説明出来ないので、そちらは他に譲る。アクセスの説明でも趣味の色が出ている。それを他のデーターベースでやると、さらに軸がブレてしまってまとまらないのが見て取れるので今回は外しました。一通りは扱えるぐらいは理解しているのが私です。
このデータベースの話を通して言えることは、淡い期待でアクセスを使い始められると、すぐに裏切られるようなると思う。アクセスは汎用性を重視して作られているソフトと割り切って使って欲しいです。汎用性を重視すると、どうしても余分な処理や機能が付属してしまって、見ても分かり難くなる傾向がある。SQLやフォーム・レポートの肝心な部分を抜き出せるまで、使いこなせたらアクセスも面白いソフトになると思います。
具体的な使い方まで、このブログに入れたらすぐに利用可能な物ったけど、作り方から入るのは珍しいブログになると思ったのでここまで勢いで書きました。
プログラムを作るのに時間が掛かったのが、ちょっとした修正作業。
これがなくても動いただろうけど、見た目も悪いし人に使って貰うのが前提だったので、ちょっとでも見易くしたいというので苦労しました。
プログラムの修正などでもMIFESを使って、データの修正や書き込みを何度もアクセスの編集画面と往復して仕上げたりしていたので、MIFESが無かったらと思うとゾッとします。
テーブル名を一括変換して、別のクエリーに使ったり。フィールド名の変更を間違いなく全て一字一句を完璧にやるとか人間業とは思えない作業もMIFESを使えばストレスなく出来ました。
希望を入れると、よそのプログラム作成総合環境のエディターなどでやられている。編集作業をするエディターの指定などが出来たらば、かなり使いやすくなる思う。それは私の使っていたアクセスのバージョンでは無理だったので、ひたすらカットアンドペーストを繰り返していたのを思い出します。
やろうと思えば、エディターの動くメモリーなどのスペースを余分に空けといて、そこで使うデータの共有化をはかるだけの話なので、MSのやる気だけの問題なんだが。
その辺りも汎用化されると、アクセスを好きになる人も出てくると思う。
うかうかしていると、総合環境のデータベース作成機能がアクセスの汎用性を追い越してしまって、使う人が激減するのでは？って門外漢ながらちょっと心配してます。プログラムを専門職でやられるなら、MSのVisual Studioなど使われているだろうけど、私はそこまで専門でもないので、総合環境については良いなぁーてぐらいでまだ使いこなしていないのであしからず。年々、機能が豊富になっていて使いやすくなる総合環境、PCを買い換えたらすぐに試してみたいと思う今日この頃。
アクセスで作ったプログラムの具体的な使い方・作り方は、私の勤務する会社でアクセスのバージョンアップをするタイミングを見て、思い出しながら最新バージョンに合わせてカスタマイズしつつ使い方・作り方を載せる事になると思います。それまでは、このブログの内容に近い物を公開するぐらいになると予定しています。今の所バージョンアップの予定は聞いていないので、いつになるか不明です。