概要
| この記事の結論 フォームのチェック状態をテーブルへ保存するには、フォームのレコードソースに保存先を含め、チェックボックスのコントロールソースをYes/No型のフィールド名に設定します。そのうえでレコードを保存し、同じ主キーの行で反映を確認します。チェックが付いた見た目だけでは保存完了とは限りません。連結先、更新可能性、保存時のエラー、確認しているデータの場所を順番に調べましょう。 連結チェックボックスとは、テーブルの特定フィールドに結び付け、レコードごとのオン・オフを表示・更新する入力部品です。 |
この記事でわかること
- 保存先のテーブルと対象レコードを特定する
- フォームとチェックボックスを正しく連結する
- 保存を確定し同じ主キーで反映を確認する
- 症状別に更新できない原因を切り分ける
この記事の主な内容
- 反映されないときは保存までの経路を確認する
- 保存先のテーブルと対象レコードを特定する
- フォームとチェックボックスを正しく連結する
- 保存を確定し同じ主キーで反映を確認する
- 症状別に更新できない原因を切り分ける
- 複数人利用と監査を考えた運用に整える
- まとめとよくある質問
想定読了時間：約15分～20分
反映されないときは保存までの経路を確認する
チェックが付くことと、テーブルに保存されることは別です。既存フォームを直す場合は、最初に「どのデータを表示しているか」「どの項目へ書き込むか」「保存が完了したか」の3点を確かめます。画面を作り直す前に、この経路を追うと変更箇所を絞れます。
保存先を持つチェックかを見分ける
業務データを更新するチェックは、テーブルのフィールドと結び付いた「連結コントロール」にします。一方、「未確認だけ表示する」という検索条件は、保存先を持たない非連結でも構いません。検索用のチェックを業務フラグに結び付けると、検索のつもりでデータを変更する危険があります。
| 用途 | コントロールソース | 結果 |
|---|---|---|
| 受注を確認済みにする | 確認済 | 対象レコードの値を更新する |
| 確認済みだけを検索する | 空欄 | 画面上の条件として使う |
| 条件に合うかを表示する | =比較式 | 計算結果を表示し、直接保存しない |
ここでいうコントロールソースは、入力部品の「保存先または表示する式」です。フォーム全体のレコードソースは「画面の元になるテーブルやクエリ」です。名前が似ていますが、片方だけの設定では正しく保存できません。
まず変更前の状態を記録する
業務用ファイルのコピーを用意し、フォーム名、チェックボックス名、レコードソース、コントロールソースを控えます。外部DBにリンクしている場合、フロントのコピーだけではデータは分離されません。検証用データへ接続するか、影響を限定できるテストレコードで確認してください。
保存先のテーブルと対象レコードを特定する
保存確認には、名前や画面上の行番号ではなく主キーを使います。主キーとは、1件のデータを一意に識別する項目です。受注番号が重複する設計なら、内部の受注IDなど確実に1件を特定できる値を選びます。
練習用の構成
本記事では、架空のT_受注をF_受注確認で編集する例を使います。既存システムでは項目名をそのまま変更せず、現在の構造と次の役割を照らし合わせてください。チェックのラベルは「確認済」、部品の名前はchk確認済として区別します。
| 対象 | 設定例 | 確認する意味 |
|---|---|---|
| テーブル | T_受注 | 実際に値を保存する場所 |
| 主キー | 受注ID／オートナンバー | 変更する1件を識別する |
| 表示項目 | 件名／短いテキスト | 利用者が内容を確認する |
| 保存項目 | 確認済／Yes/No型 | 確認したかどうかを保持する |
| フォーム | F_受注確認 | 対象レコードを表示する画面 |
Yes/No型の値は、AccessではTrueが-1、Falseが0として扱われます。外部システムへ出力するときに1と-1を混同しないよう注意します。ただし、今回の連結設定では数値を手入力する必要はなく、フィールド名を指定します。
見ているファイルと接続先をそろえる
画面が受注ID「101」を表示しているなら、テーブルでも101を探します。さらに、ファイル名が同じでも保存フォルダーが違うコピーでないかを確認します。リンクテーブルの場合は、そのリンクが本番DBとテストDBのどちらへ向いているかまで調べます。
既定値Falseは、新規入力の初期値です。既存の確認済データをまとめてFalseへ戻すための設定ではありません。既定値だけ変更して「過去のチェックが消えない」と判断しないようにしましょう。
フォームとチェックボックスを正しく連結する
フォーム全体の設定を確認してから、チェックボックスの設定へ進みます。コントロールソースに入れるのは、通常「確認済」というフィールド名です。「chk確認済」という部品名や「T_受注.確認済」といった推測した文字列を入力する前に、選択リストに対象項目が出るかを確認します。
手順1 フォームのレコードソースを確認する
1. ナビゲーションウィンドウでF_受注確認を右クリックし、［デザインビュー］で開きます。
2. F4でプロパティシートを表示し、上部の選択対象を［フォーム］にします。
3. ［データ］タブの［レコードソース］を確認します。例ではT_受注を指定します。
4. クエリが指定されている場合は、その出力列に受注IDと確認済が含まれているか確認します。
5. クエリ自体を開いて、確認済フィールドが更新可能かをテスト用レコードで確かめます。
集計や重複を除く処理を含むクエリは、その結果を直接更新できない場合があります。フィールドが表示されることだけでは更新可能とは限りません。保存用のフォームは更新可能なレコードソースを使い、集計結果は別の一覧やレポートで見せると役割を分けられます。
手順2 チェックボックスを選ぶ
1. 四角いチェックボックス本体をクリックします。横のラベルを選ばないようにします。
2. プロパティシートの選択対象がチェックボックスであることを確認します。
3. ［データ］の［コントロールソース］で確認済を選択します。
4. ［使用可能］を［はい］、入力させる場合は［編集ロック］を［いいえ］にします。
5. フォームの設計を保存し、フォームビューへ切り替えます。
オプショングループ内のチェックボックスは例外です。独立したYes/Noのチェックとは保存の仕組みが異なり、グループ側の値と連結先を使います。複数の状態を1つ選ぶ目的なら、オプショングループまたはコンボボックスとして設計してください。
保存を確定し同じ主キーで反映を確認する
設定後は、既存レコード1件を使ってオンとオフの両方を確認します。レコードを移動すると通常は保存が行われますが、必須項目や入力規則に違反すると保存できません。エラーが出た場合は、そのまま閉じて成功と判断せず、メッセージの項目名を確認します。
コードを使わない確認手順
1. テスト用の受注IDを控え、現在の確認済の値を確認します。
2. フォームでチェックを変更します。
3. ［ホーム］のレコード保存操作を実行するか、別レコードへ移動します。
4. 保存時のエラーがないことを確認し、フォームを閉じて開き直します。
5. 同じ受注IDに戻り、チェック状態を確認します。
6. テーブルを開き直すか最新表示にし、同じ主キーの値と比較します。
フォームの設計を保存する操作と、編集中のレコードを確定する操作は目的が異なります。Ctrl＋Sだけを成功判定にせず、再表示した値とテーブルの値で確認してください。主キーによる確認用の選択クエリを用意すると、行を探し間違えるのを防げます。
SELECT [受注ID], [確認済]
FROM [T_受注]
WHERE [受注ID] = 101;
101は説明用の値です。実際に存在するテスト用IDへ置き換えます。このSELECTは閲覧のための例で、データを変更しません。
保存ボタンを付ける場合
明示的な保存ボタンが必要なら、F_受注確認にcmd保存を配置し、その［クリック時］イベントに次のコードを設定します。Dirtyは、表示中のレコードに未保存の変更があるかを表すプロパティです。Falseを設定して保存を試み、失敗した場合は成功メッセージを出さない構成にします。[2]
Private Sub cmd保存_Click()
On Error GoTo ErrHandler
If Me.Dirty Then Me.Dirty = False
MsgBox “レコードに未保存の変更はありません。”, vbInformation
Exit Sub
ErrHandler:
MsgBox “保存を完了できません。” & vbCrLf & _
Err.Number & “：” & Err.Description, vbExclamation
End Sub
このコードは、ボタンと保存対象のデータが同じフォームにある前提です。親フォームのボタンからサブフォームを保存するときは、対象サブフォームを明示して設計します。また、フォームの更新前イベントで保存を取り消している場合もあるため、既存の入力チェックと併せて確認してください。
症状別に更新できない原因を切り分ける
コントロールソースが正しくても、編集制限や接続先の権限によって保存できない場合があります。原因を一度に直そうとせず、保存経路の手前から確認します。業務用の編集禁止設定を理由なく解除することは避けてください。
| 症状 | 主な確認箇所 | 対応の方向 |
|---|---|---|
| クリックできない | 使用可能・編集ロック・フォームの更新許可 | 意図した入力権限か確認する |
| クリックできるが残らない | 連結先の空欄・計算式・保存エラー | フィールドへ連結し保存を確認する |
| 保存時に警告が出る | 必須項目・入力規則・更新前イベント | 警告の対象を修正する |
| テーブルでは値が違う | 主キー・ファイル・リンク先・表示の更新 | 同じデータを見ているか確認する |
| 複雑な一覧だけ更新できない | 集計や結合を含むレコードソース | 更新用と表示用を分ける |
| 他のPCだけ保存できない | 共有先・DB権限・接続設定 | 利用者の接続条件を比較する |
連続フォームで全部のチェックが変わる
連続フォームは、同じコントロールの配置をレコードごとに繰り返して表示します。非連結のチェックは各行の保存値を持たないため、全行が同じ状態に見えることがあります。レコードごとの状態を残したいなら、その行のフィールドへ連結してください。
ただし、全行が見た目だけ変わった場合と、更新クエリなどで実データが一括変更された場合は別です。最初にテーブルの値を確認し、本当に全件が変わったか切り分けます。WHERE条件のない更新処理がないか調べるのは、その後です。
Nullを未確認と同じ意味にしない
Nullは値が不明または未設定という意味です。非連結コントロールや外部DBのNULLを含むデータでは、三状態の設定によって灰色表示などになる場合があります。三状態は表示・入力の扱いであり、Accessの通常のYes/No項目を「未確認・承認・却下」の3値管理へ変える機能ではありません。
承認状態などが3種類以上ある場合は、状態コードと選択肢を設ける方が意味を明確にできます。外部DBのNULLをFalseとして表示する場合も、元データまでFalseに更新するのか、表示だけ置き換えるのかを決めてください。
Accessの設定や運用で解決が難しい場合は
設定変更だけで改善しない場合や、複数人での利用・外部DB・既存のVBAが関わる場合は、原因と影響範囲を整理してから改修を進めましょう。Accessの教科書では、既存Accessの修正や運用の見直しについて相談できます。対象画面、症状、再現手順をまとめると、調査の相談がしやすくなります。
複数人利用と監査を考えた運用に整える
業務上の「確認済」と、その利用者だけが選んだ「今回の処理対象」は分けて管理します。共有テーブルに一時選択を保存すると、別の利用者の選択が混ざる可能性があります。個人の作業対象は利用者や処理単位を識別する作業テーブルなどで設計します。
確認した人と日時も必要かを決める
Yes/Noだけでは、誰がいつ変更したかを説明できません。履歴が必要なら確認者ID、確認日時、取消理由などの記録を別途設計します。フォーム側だけで記録してもテーブルを直接更新できる運用では記録が抜けるため、更新経路全体をそろえる必要があります。
変更後のテスト
| 確認する操作 | 期待する結果 |
|---|---|
| 既存行のオン・オフ | 再度開いても指定した値が残る |
| 新規行の登録 | 必須項目を満たしたときだけ保存できる |
| 入力規則違反 | 保存できない理由が分かり、成功表示しない |
| 別レコードへの移動 | 別の主キーの状態は変わらない |
| 2台で同じレコードを編集 | 競合時の警告と対応手順が確認できる |
| 配布先PCで起動 | 同じ接続先で保存・再表示できる |
まとめ
チェック状態の保存は、レコードソース、コントロールソース、レコード保存の順に確認します。最終的には同じ主キーのテーブル値と照合し、オン・オフ、新規・既存、別PCでの挙動を確かめましょう。連結が正しい場合は、更新できないクエリ、入力チェック、外部DBの権限などへ調査を進めます。
よくある質問
画面の値が変わっても、保存先に連結されていない場合はテーブルへ残りません。まずチェックボックス本体のコントロールソースが、保存したいフィールド名になっているか確認します。次にレコードを保存し、必須項目や入力規則のエラーがないか調べてください。フォームを開き直して同じ主キーを表示し、テーブルの値と照合します。別のコピーや別の接続先を見ていないかも確認すると、設定不良と確認場所の違いを切り分けられます。
通常は、フォームのレコードソースに含まれているフィールド名を設定します。確認済というYes/No型の項目へ保存するなら「確認済」を選びます。チェックボックス自身の名前や、横に表示されるラベルの文字を入れる欄ではありません。先頭に等号を付けた式は計算結果を表示する用途です。候補に目的の項目が出ない場合は、フォームのデータ元のクエリにその列が含まれるか、フィールド名が変更されていないかを確認してください。
Ctrl＋Sを押したことだけでは、業務データが保存できたとは判定できません。フォームの設計保存とレコードの保存を区別し、入力後はレコード保存操作や別レコードへの移動で確定させてください。必須項目の不足や更新前イベントによる取消があれば、保存が成立しない場合があります。明示的な保存ボタンを使う場合も、エラーを表示する処理が必要です。最後にフォームを開き直し、同じ主キーの値が残っているか確かめます。
非連結チェックを連続フォームの詳細部に置くと、各レコードの値に結び付いていないため、繰り返し表示された行が同じ状態に見えることがあります。レコード単位の状態を保存するなら、Yes/No型のフィールドへ連結します。まずテーブルを確認し、見た目だけの変化か、実際に複数行が更新されたのかを分けてください。一時的な複数行選択が目的なら、共有の業務フラグを流用せず、利用者や処理単位を識別できる仕組みを検討します。
はい。正しく連結したYes/No型の項目では、チェックありとチェックなしの両方が保存対象です。外した後に別レコードへ移動するなどして保存し、元のレコードへ戻って確認します。オンだけ残ってオフが残らない場合は、更新イベントでTrueを代入していないか、既定値と保存値を混同していないかを調べてください。既定値をFalseにしても過去のデータは一括変更されません。テストではオンからオフと、オフからオンの両方向を確認します。
Nullを表示する設定や、コントロールが使用不可になっている状態などが考えられます。Nullは単なる「いいえ」ではなく、値が未設定・不明という意味です。三状態の設定、コントロールソース、外部DBのNULLの有無を確認してください。通常のYes/No項目へ三状態を設定するだけで、3種類の業務状態を保存できるわけではありません。未確認・承認・却下のような分類なら、状態コードを持つ項目とコンボボックスなどで明示的に管理します。
共有のYes/No項目を作業対象選択に使うと、別の利用者が付けたチェックと混ざるおそれがあります。「受注を確認済みにした」という全員共通の業務状態と、「自分が今回処理する」という一時的な選択は分けてください。後者は利用者IDや処理IDを持つ作業テーブルなどで管理します。また、同じレコードを同時更新すると競合する場合があるため、複数PCで警告と再読込の手順を確認します。履歴が必要なら変更者と日時の記録も設計します。
Accessの設定や運用で解決が難しい場合は
設定変更だけで改善しない場合や、複数人での利用・外部DB・既存のVBAが関わる場合は、原因と影響範囲を整理してから改修を進めましょう。Accessの教科書では、既存Accessの修正や運用の見直しについて相談できます。対象画面、症状、再現手順をまとめると、調査の相談がしやすくなります。
関連記事
参考情報
[1] Microsoft｜CheckBox.ControlSource
https://learn.microsoft.com/en-us/office/vba/api/access.checkbox.controlsource
[2] Microsoft｜Form.Dirty
https://learn.microsoft.com/en-us/office/vba/api/access.form.dirty%28property%29
[3] Microsoft｜CheckBox.TripleState
https://learn.microsoft.com/en-us/office/vba/api/access.checkbox.triplestate
[4] Microsoft｜Form.AllowEdits
https://learn.microsoft.com/en-us/office/vba/api/access.form.allowedits
[5] Microsoft｜クエリのデータを編集する
https://support.microsoft.com/ja-jp/access/edit-data-in-a-query