連結フォームと非連結フォームの違い(メリット、デメリット)
仕事でAccessの開発案件に携わることがあったので、その時に調査した内容をメモとして残しておこうと思います。
まず、Accessの開発で最初に躓いたのは、テーブルに対してレコードの検索や登録をする画面を、連結フォームで作成するのか、それとも非連結フォームで作成するのか、で迷ったことです。
結論としては、連結フォームは簡単に作ることができていいですが、Access既定の動作と違うことをさせようとすると大変だったので、作成する画面の構成で判断するのがいいと思います。ただし、開発していくうちに画面が最初の仕様と違ってくることは多々あるので、仕事の案件で相手がいるような開発なら非連結で(『Access既定の動作なので~』という説明で納得してくれる相手なら連結でもよい)、個人やプライベートなら連結でしょうか。
目次
- 連結、非連結フォームの設定方法
- 連結フォームの特徴
- 非連結フォームの特徴
- 開発にかかる工数の違いと個人的な見解
- 余談
連結、非連結フォームの設定方法
画面(フォーム)を連結または非連結として作成するかどうかの設定は、フォームのプロパティから選択可能で、プロパティ「レコードソース」にテーブルが指定されている場合、その画面は連結フォームとなります。
連結フォーム上にテーブルの項目と結び付けたコントロールを配置してフォームを開くと、テーブルへの操作をAccessが自動でやってくれて、以下のようにコードをかかずにデータの取得、または修正といったことが可能になります。
逆に非連結フォームは、フォームのプロパティ「レコードソース」を空にした状態になります。
実際に空にして先ほどのフォームを同じように開くとデータが表示されなくなります。
このため、非連結フォームの場合は、データの取得や登録処理といったものを自分で用意しないといけません。
連結フォームの特徴
連結フォームで画面を作成することのメリットは以下の通りです。
- 簡単に登録画面を作成できる
- データベースへの登録処理を自分で書かなくて済む
- レコードセレクタや移動ボタンが使えて便利
逆にデメリットは冒頭にも述べた通り、Access既存の動作から逸脱した処理を実装しようとするとかなり面倒な点で、場合によっては不可能な場合があることです。
例えば、テーブルにオートナンバー型のIDを使っている場合、Accessの連結フォームでテーブルと紐づいた項目に何かしらの入力を行うと、その時点でレコードが作成されてしまうので、途中で入力をやめて、そのレコードを削除したとしても、オートナンバーの値は戻らず、次回の登録でIDが欠けた状態になります。
私が試してみた限り、テーブルへのデータの登録自体は「登録ボタン」が押されたタイミングでするなど、調整が可能でしたが、このオートナンバーの抜け番に関してだけはどうにもなりませんでした。
そのため、テーブルにオートナンバーは使っているけど、抜け番は好ましくない、と考えている人は、次に示す非連結フォームで作成する必要があります。
なお、連結フォームはテーブルを開いた際の動作とほとんど同じだったので、認識としてはテーブルのデータ編集機能にプラスαした画面が連結フォームになるかと思います。
非連結フォームの特徴
非連結フォームで画面を作成することのメリットは以下の通りです。
- 設計や製造でAccess既定の動作に振り回されることが少ない
- 画面の入力とデータベースへの登録を完全に分けて作成することができる
連結フォームでデメリットとして挙げた『オートナンバー』の抜け番にしても、非連結フォームであれば、登録ボタンを押さない限りデータベースへの書き込みを一切しないように作れるので、問題にはなりません。
デメリットは、連結フォームでメリットとして挙げた「レコードの登録や選択」といった処理を自分でVBAで書く必要があることです。
このため、非連結フォームの画面を一から作る場合、連結フォームの画面を作成するよりも最初は時間がかかります。
開発にかかる工数の違いと個人的な見解
連結フォームと非連結フォームで画面を作成した場合の開発にかかる工数の違いは、最初は連結フォームで作成した方が簡単なので物ができるのは速いですが、作り込んでいくとAccess既定の動作をなんとかしようとして調査が度々入り、それでハマることが多いので、個人的には非連結フォームで作成した方が最終的な工数は少なくなります。
なので、相手がいる案件で『納品した後は自分たちで手を加えたいのでコードは必要最小限にして画面は連結フォームで作ってほしい』と言われでもしない限り、テーブルへのレコード登録などを行う画面は、非連結フォームで作成するのがいいかと思います。
余談
余談ですが、Accessについてはだいぶ前に一度だけ開発でやったことがあり、そこまで抵抗感はありませんでしたが、Web全盛の時代に今でもAccessの開発案件があるとは思いませんでした。
そのため、この仕事の話が来た時は「え、今時、Access?」と思いましたが、実際にやってみると、テーブルや画面が簡単に作成できて、そこまでパフォーマンスを必要としない利用者が数人程度のシステムであれば、ちゃちゃっと作ることができて楽です。
作成または使用するためには、Accessのアプリが必要になるので有料にはなりますが、Webアプリの場合はサーバーを用意したり管理に時間を割いたりする必要があるので、ランニングコストという面での違いはそこまでないように思います。広く配布するには向きませんが、限られた環境下で使うなら、これはこれでありですね。