概要
| この記事の結論 単票フォームは、1画面で1件ずつレコードを表示・編集するフォームです。フォームウィザードで元テーブルと項目を選び、単票形式を指定すると作成できます。作成後は連結先を確かめ、入力・レコード移動・再表示で保存を確認しましょう。 |
この記事でわかること
- 単票は表示形式
- 保存先はテーブル
- 新規専用設定は別
- 再表示で保存を確認
この記事の主な内容
- 単票フォームと一覧形式の使い分け
- 練習用の顧客テーブルを準備する
- フォームウィザードで単票フォームを作る
- デザインビューで連結先と入力順を整える
- 保存と取消しの動きを確かめる
- 表示されない入力できない場合の対処
- 受注明細への応用と完成確認
- よくある質問
想定読了時間：約12分～16分
単票フォームと一覧形式の使い分け
単票フォームは、現在の1レコードを中心に表示・編集する入力画面です。顧客の名前、連絡先、備考などを広く配置できるため、1件ずつ内容を確認する仕事に向いています。元のテーブルに保存できる件数を1件に制限する機能ではありません。
例えば顧客が100件ある場合でも、画面には現在選んだ1件を表示し、レコード移動で別の顧客へ切り替えます。「単票」は見せ方、「新規入力専用」は操作目的です。既存レコードを表示するかどうかは、別のプロパティで設定します。
| 表示形式 | 向いている作業 | 選ぶときの注意 |
|---|---|---|
| 単票フォーム | 1件の詳しい入力・確認 | 複数件の比較には移動が必要 |
| 帳票フォーム（連続フォーム） | 複数件を並べて確認 | 1件分の高さと列数を抑える |
| データシート | 表形式で一覧や入力 | 詳細な説明文の配置には不向き |
画面に多くの項目があるときは、単票で入力欄を分類すると使いやすくなります。一覧から顧客を選び、詳細を単票で開く構成も可能です。まず利用者が「1件を詳しく扱う」のか「複数件を比べる」のかを決めましょう。
練習用の顧客テーブルを準備する
フォームの前に、保存先のテーブルを作ります。今回は顧客1人または1社を1レコードとして扱うM_顧客を用意します。既存データベースを使う場合はコピーで試し、同名のテーブルやフォームを上書きしないようにしてください。
保存する項目とデータ型
［作成］から［テーブルデザイン］を開き、次のフィールドを登録します。顧客IDを選び、主キーを設定してM_顧客として保存します。主キーとは、各レコードを重複なく区別するための項目です。名前が同じ顧客でも、IDが異なれば区別できます。
| フィールド | データ型 | 設定の考え方 |
|---|---|---|
| 顧客ID | オートナンバー型 | 主キー。利用者に採番させない |
| 顧客名 | 短いテキスト | 必須。空文字を許可しない設計を検討 |
| 電話番号 | 短いテキスト | 先頭の0やハイフンを保持 |
| 備考 | 長いテキスト | 複数行の補足を記録 |
電話番号は計算に使わない識別情報なので、数値型にする必要はありません。郵便番号や商品コードも、先頭の0を残す必要があるかで判断します。また、同姓同名を許す業務で顧客名に重複禁止を設定すると、正しい登録まで拒否してしまいます。
先に2件入れておく理由
テーブルにテスト用の顧客を2件登録してからフォームを作ると、既存データの表示とレコード移動を確認できます。実在の個人情報を使う必要はありません。「テスト顧客A」「テスト顧客B」など、後で識別・削除できるデータにします。
テーブルはデータの保存場所、フォームは入力・表示の窓口です。フォームを複数作っても、同じテーブルに連結していれば同じデータを扱います。画面を複製しただけで顧客データが別々に複製されるわけではありません。
フォームウィザードで単票フォームを作る
初心者はフォームウィザードで元データと項目を選ぶ方法から始めると、入力欄の連結先を設定しやすくなります。今回は単一テーブルを元に作り、複数テーブルを使う画面は基本動作の確認後に扱います。参考1
四つの操作で作成する
1. ［作成］タブの［フォームウィザード］を開きます。
2. テーブル／クエリでM_顧客を選び、顧客ID・顧客名・電話番号・備考を選択したフィールドへ移します。
3. レイアウトで［単票形式］を選びます。画面名や選択肢の位置はAccessのバージョンで異なる場合があります。
4. フォーム名をF_顧客単票にし、フォームを開く指定で完了します。
フォームビューで顧客Aが表示されたら、下部のレコード移動ボタンで顧客Bへ進みます。ここで2件が切り替われば、単票形式とデータの連結を確認できます。表示されない場合は、次の節のレコードソースと、後述するデータ入力用の設定を調べます。
［作成］の［フォーム］を使って自動生成する方法もあります。ただし、関連テーブルの状態によってはサブフォームなどが加わることがあります。今回の練習では、選ぶテーブルとフィールドが明確なウィザードを使うと、結果を把握しやすくなります。
デザインビューで連結先と入力順を整える
作成後は見た目を整える前に、フォーム全体と入力欄の連結先を確認します。フォーム全体の「レコードソース」はデータの取得元、入力欄の「コントロールソース」はその欄に表示・保存するフィールドです。二つは同じ設定ではありません。参考3
フォーム全体と入力欄を選び分ける
ナビゲーションウィンドウでF_顧客単票を右クリックし、デザインビューで開きます。F4でプロパティシートを表示し、選択対象を［フォーム］にします。［データ］のレコードソースがM_顧客、［書式］の既定のビューが単票フォームになっているか確認します。
次に顧客名のテキストボックス本体を選びます。隣のラベルではなく、値を表示する入力欄を選ぶ点が重要です。コントロールソースが顧客名であれば、その欄とフィールドが連結しています。ラベルの標題を変えても、保存先は変更されません。
| 対象 | プロパティ | 今回の設定 |
|---|---|---|
| フォーム全体 | レコードソース | M_顧客 |
| フォーム全体 | 既定のビュー | 単票フォーム |
| 顧客名の入力欄 | コントロールソース | 顧客名 |
| 顧客名の入力欄 | 名前 | txt顧客名など、識別できる名前 |
| 顧客名のラベル | 標題 | 顧客名など、利用者向けの表示 |
コントロールソースが空なら非連結の入力欄です。検索条件の入力には使えますが、そのままでは顧客テーブルへ保存されません。また、コントロールソースが「=」で始まる計算式なら、表示する値を計算する欄です。通常の保存用入力欄と区別してください。
入力しやすい画面にする
顧客IDは自動採番なので、表示専用として編集ロックを設定し、タブストップを外す方法があります。顧客名、電話番号、備考の順に移動できるよう、［タブオーダー］で順序を調整します。備考欄は複数行を見やすい高さに広げます。
入力欄の幅を変える際は、画面の表示倍率も確認します。作成者の大きなモニターで収まっていても、利用者の画面では右側が隠れることがあります。必須欄には「必須」などの文字も添え、色だけで区別しないようにすると伝わりやすくなります。
Accessの教科書で入力フォームの作成と改修を相談する
ここまでの手順を試しても解決しない場合や、既存業務への影響を判断しにくい場合は、対象画面・現在の設定・再現手順を整理してご相談ください。Accessの教科書のお問い合わせ窓口から、状況に合う対応方法を相談できます。
保存と取消しの動きを確かめる
連結フォームでは、別レコードへ移動したときなどにレコードの保存が行われます。保存ボタンがないから未保存、とは限りません。一方、フォームの配置を保存する操作と、入力データを保存する操作は別です。入力後は元テーブルや再表示で結果を確かめます。
追加・変更・取消しを別々に試す
1. フォームビューで新しい空白レコードへ移動し、テスト顧客Cを入力します。
2. 別のレコードへ移動してから戻り、顧客Cが残っているか確認します。
3. 顧客Cの電話番号を変更し、レコードを保存して再表示します。
4. 保存済みの顧客を編集し、保存前に取消し操作を試します。変更前の値へ戻るか確かめます。
5. フォームを閉じ、テーブル側でも値を確認します。確認後にフォームを開き直します。
取消しは、まだ保存していない編集内容を戻す操作です。保存後の値まで過去へ戻せる仕組みではありません。Escは状況に応じて入力欄の編集を取り消し、さらにレコード全体の変更を取り消す操作になります。取り消した範囲を画面で確認してください。
任意で保存ボタンを付ける
保存したことを利用者に明示したい場合は、コマンドボタンに次のような処理を設定できます。ボタン名をcmdSaveとし、クリック時のイベントプロシージャへ記述します。これは例示コードです。実際のフォーム名、入力規則、イベントと合わせて動作確認してください。
Private Sub cmdSave_Click()
On Error GoTo ErrHandler
If Me.Dirty Then
DoCmd.RunCommand acCmdSaveRecord
End If
MsgBox “レコードを保存しました。”, vbInformation
Exit Sub
ErrHandler:
MsgBox “保存できませんでした。” & vbCrLf & _
Err.Description, vbExclamation, “入力内容の確認”
End Sub
Dirtyは、現在のレコードに未保存の変更があるかを示します。必須項目の不足などで保存が失敗した場合、エラーを知らせて画面を残します。成功したときだけ完了メッセージを表示するため、保存できていないのに完了と案内する誤りを防げます。
取消しボタンを作る場合は、未保存の変更を確認してからMe.Undoを使う方法があります。「編集中の内容を取り消す」と表示し、対象範囲を明確にします。データの削除、レコードの取消し、フォームを閉じる操作を同じボタンに混在させない方が安全です。
表示されない入力できない場合の対処
不具合は、表示対象の問題と、編集を許可する設定の問題を分けて確認します。フォームを作り直す前に、元テーブルを開き、データ自体が存在するか確かめます。その後でフィルター、データ入力用、編集許可、入力欄の設定の順に調べると整理しやすくなります。
| 症状 | 主な確認箇所 | 対応の方向 |
|---|---|---|
| 新規行だけが出る | データ入力用、フィルター | 既存も扱うならデータ入力用を「いいえ」に |
| 新規追加できない | 追加の許可、元クエリ | 追加を許可し、更新可能な元データか確認 |
| 既存の値が編集できない | 更新の許可、編集ロック | フォームと入力欄を別々に確認 |
| 入力しても保存されない | コントロールソース | 非連結なら保存用フィールドへ連結 |
| データ型のエラーが出る | テーブルの型、入力規則 | 数字・日付・必須条件に合う値を入力 |
| 計算式の欄だけ編集不可 | 計算コントロール | 計算元の項目を入力する |
データ入力用と追加の許可の違い
データ入力用を「はい」にすると、フォームを開いたとき既存レコードを表示せず、新規入力を行う形になります。ただし、これ自体は追加を許可する設定ではありません。追加の許可が有効であることも必要です。参考4
既存データが見えなくても、すぐに削除されたと判断しないでください。フォームを開く処理の条件や起動時フィルターも表示対象を絞ります。元テーブルで件数を確かめ、設定を一つずつ戻して原因を探します。無関係な設定を同時に変えると原因が分からなくなります。
元クエリが編集できるか確認する
集計や一部の結合を含むクエリは、結果を編集できないことがあります。プロパティを「はい」にしても、更新できない元データが更新可能になるわけではありません。単一テーブルを元にした簡単なフォームで試し、元クエリの構成へ調査を進めます。
受注明細への応用と完成確認
1受注に複数の商品を入力したい場合は、受注を表示する単票の親フォームと、明細を表示するサブフォームを組み合わせます。親に受注日や顧客、子に商品や数量を置くことで、注文全体と明細の役割を分けられます。
サブフォームのリンクを確認する
親のレコードソースをT_受注、子をT_受注明細とし、両者に受注IDを持たせます。親フォーム上のサブフォームコントロールで、リンク親フィールドとリンク子フィールドを受注IDへ設定します。子フォーム本体の設定と、親上の配置枠の設定を選び分けてください。
親の受注を切り替えたときに、その注文の明細だけが表示されるか確認します。明細を追加するときは親レコードのキーが確定していることが必要です。テーブル間の参照整合性も設定し、存在しない受注の明細を登録しない仕組みを用意します。
入力画面を一つにまとめても、保存先を一つの表にまとめる必要はありません。また、サブフォームを配置しただけでは業務上の関係は保証されません。親子リンクとテーブルの制約を別々に確かめ、別の注文の明細が混ざらないことをテストします。
完成後に確かめること
| 確認する操作 | 期待する結果 |
|---|---|
| 既存2件を切り替える | 正しい顧客が1件ずつ表示される |
| 新規1件を追加し開き直す | 入力した値が残る |
| 必須欄を空にして保存する | 保存できず、修正できる画面が残る |
| 保存前に変更を取り消す | 変更前の内容へ戻る |
| Tabキーで入力する | 利用者が期待する順番で移動する |
| 小さい画面で開く | 必須欄と主要ボタンが見える |
単票フォームは、テーブルに保存するデータを1件ずつ扱うための画面です。ウィザードで作成した後、レコードソースとコントロールソースを確認し、保存・取消し・再表示を試せば、見た目だけでは分からない不具合を見つけやすくなります。
よくある質問
いいえ。単票は、現在の1レコードを中心に表示する形式です。元テーブルに複数件のデータがあれば、移動ボタンや検索で別のレコードへ切り替えられます。1件だけしか見えない場合は、フィルターやレコードソースの抽出条件も確認してください。新規レコードしか出ない場合は「データ入力用」の設定が関係します。件数の上限と表示形式を分けて考えると、不要なフォームの作り直しを避けられます。
連結フォームで入力したデータは、コントロールソースで結び付いたテーブルのフィールドへ保存されます。フォームには、入力欄の配置や表示設定などの設計情報を保存します。入力欄が非連結の場合は、文字を入力できても、そのままテーブルへ保存されません。フォームのレコードソースと、各入力欄のコントロールソースを確認し、テスト入力後に元テーブルや再表示で値が残るかを確かめてください。
まず元テーブルにデータが存在するか確かめます。データがあれば、「データ入力用」が「はい」になっていないか、フィルターやレコードソースの条件で絞り込まれていないかを確認します。フォームを開くマクロやVBAの条件が影響することもあります。画面に見えないことと、データが削除されたことは同じではありません。設定を一つずつ変更し、どの条件を外すと表示されるかを記録すると原因を追いやすくなります。
フォームをデザインビューで開き、フォーム全体のプロパティにある「既定のビュー」を単票フォームへ変更できます。ただし、表示形式だけを変えても入力欄の配置が自動で使いやすくなるとは限りません。まずフォームを複製して試し、詳細セクションの高さ、入力欄の幅、タブオーダーを調整してください。集計欄や独自の移動処理がある場合は動作も確認します。元フォームを残せば、問題があっても比較して戻せます。
連結フォームではレコード移動などで保存されるため、保存ボタンは必須ではありません。ただし、利用者が保存のタイミングを理解しにくい業務では、明示的なボタンが役立ちます。ボタンを設ける場合は、必須項目の不足や入力規則違反で保存できなかったときに、完了と表示しないようにします。また、保存ボタンがなくても保存される場面があることを案内し、取消しで戻せるのは未保存の変更であると説明してください。
電話番号は通常、短いテキスト型で管理します。数値型にすると、先頭の0やハイフンなどを期待どおり保持できないためです。計算する数量・金額と、人や物を識別する番号は役割が異なります。郵便番号や商品コードも同様に検討してください。入力定型や桁数制限を付ける場合は、国際番号や内線番号などの実際の入力例も確認します。表示をそろえるための制約で、必要な番号を登録できなくしないことが大切です。
はい。受注を表示する単票の親フォームに、明細を一覧で表示するサブフォームを配置します。親子の保存先に受注IDを持たせ、サブフォームコントロールのリンク親フィールドとリンク子フィールドを対応させます。親の受注を切り替えた際に、その注文の明細だけが表示されるか確認してください。新規明細の追加時には親のキーが確定している必要があります。画面上のリンクに加え、テーブルの参照整合性も設定します。
関連記事
Accessコンボボックスに複数列を表示する方法と保存値の設定
Accessの教科書で入力フォームの作成と改修を相談する
ここまでの手順を試しても解決しない場合や、既存業務への影響を判断しにくい場合は、対象画面・現在の設定・再現手順を整理してご相談ください。Accessの教科書のお問い合わせ窓口から、状況に合う対応方法を相談できます。
参考情報
参考1 Microsoft フォームウィザード
https://support.microsoft.com/en-us/access/create-a-form-by-using-the-form-wizard
参考2 Microsoft 既定のビュー
https://learn.microsoft.com/en-us/office/vba/api/access.form.defaultview
参考3 Microsoft レコードソース
https://learn.microsoft.com/en-us/office/vba/api/access.form.recordsource
参考4 Microsoft データ入力用
https://learn.microsoft.com/en-us/office/vba/api/access.form.dataentry
参考5 Microsoft DoCmd.Close
https://learn.microsoft.com/en-us/office/vba/api/access.docmd.close