概要
| この記事の結論 Accessのフォームで#Name?と表示されたら、まず対象テキストボックスのコントロールソースと、フォームのレコードソースに含まれるフィールド名を照合します。デザインビューで正しい項目に直し、フォームビューで表示を確認しましょう。計算欄の場合は、式の中の名前や参照先も確認します。変更前にはバックアップを取り、コピーで試すと安心です。 |
この記事でわかること
- #Name?の意味と、2つのソースの役割
- デザインビューから行う基本の修正5ステップ
- フィールドが候補にない場合や、計算欄だけで起きる場合の確認方法
- 修正後の動作確認と、名前変更による再発の防ぎ方
この記事の主な内容
- Accessフォームの#Name?とは？最初に確認する2つの設定
- #Name?を直す基本の5ステップ
- 直らない場合はレコードソース・計算式・参照先を確認
- 修正後の確認と#Name?の再発防止
- Accessフォームの#Name?に関するよくある質問
- まとめ：参照先を順に確認し、原因が不明なら調査を依頼
想定読了時間：約12分
Accessフォームの#Name?とは？最初に確認する2つの設定
フォームの#Name?は、表示に使う式や参照で指定した名前をAccessが解決できないときに現れるエラー表示です。まず、エラーが出ている部品の設定と、その部品が参照するデータの項目名を照合します。
例えば「顧客名」というフィールドを表示したいのに、テキストボックスが存在しない「顧客名称」を参照していると、正しく値を取り出せません。画面に#Name?が出たことだけで、保存していたデータが消えたと判断する必要はありません。
レコードソースとコントロールソースの違い
フォーム全体のデータ元を指定するのが「レコードソース」、テキストボックスに表示するフィールドや式を指定するのが「コントロールソース」です。どちらもデータに関する設定ですが、設定する対象が異なります。
| 設定対象 | プロパティ | 指定内容の例 |
|---|---|---|
| フォーム全体 | レコードソース | テーブル名、クエリ名、SQL文 |
| テキストボックス | コントロールソース | 顧客名などのフィールド名、または計算式 |
| テキストボックス | 名前 | txt顧客名など、部品を識別する名前 |
| ラベル | 標題 | 画面に表示する「顧客名」などの見出し |
テーブルに「顧客名」があっても、フォームが使うクエリにその項目が含まれていなければ、そのまま連結先として使えるとは限りません。「元テーブルにあるか」に加えて、「現在のフォームが受け取る項目にあるか」を確認することが大切です。
部品の名前だけを変更しても直らない
「名前」プロパティは、マクロやVBAなどから部品を識別するための設定です。名前を「顧客名」に変更しても、コントロールソースに誤った項目名が残っていれば、参照先の修正にはなりません。
なお、連結されたテキストボックスの名前と、元のフィールド名が同じになることはあります。Microsoftの資料でも、フィールドから部品を作成すると、そのフィールド名が部品名に使われることが説明されています。同名だから必ずエラーになる、という理解は避けましょう。
#Name?を直す基本の5ステップ
基本の対処は、対象テキストボックスのコントロールソースを、実際に存在するフィールド名へ修正することです。ここでは、架空の顧客台帳を例に、変更前の準備から表示確認までを説明します。
ステップ1 バックアップを取りコピーを開く
作業前に元のAccessファイルを保存し、利用者が閉じていることを確認したうえで、組織の手順に沿ってバックアップを取ります。修正は原本ではなく作業用コピーで試し、変更前のコントロールソースも記録しておきましょう。
リンクテーブルを使っている場合、画面側のファイルをコピーしても、リンク先は本番データのままということがあります。後述の入力・保存テストは検証用データに接続して実施してください。リンク先が不明なときは、保守担当者に確認します。
関連記事：Access バックアップを取る方法
ステップ2 フォームをデザインビューで開く
対象のフォームを閉じ、ナビゲーションウィンドウでフォーム名を右クリックして［デザインビュー］を選びます。フォームを開いている場合は、ビュー切り替えからデザインビューに移動する方法もあります。
デザインビューを使えないRuntime環境や、フォーム設計の変更が制限されるACCDEでは、この手順で修正できません。製品版Accessと編集可能な原本を管理している担当者に、フォーム名と症状を伝えてください。
関連記事：Access デザインビューの使い方
ステップ3 対象のテキストボックスを選択する
フォームビューで#Name?が出ていた位置のテキストボックスをクリックします。隣にある「顧客名」などの見出しはラベルなので、値を表示する枠の方を選んでください。選択した部品が違うと、目的の設定が見つかりません。
F4キー、またはリボンの［プロパティシート］から設定欄を開きます。プロパティシート上部の選択対象がテキストボックスになっていることを確かめ、［データ］タブを開きましょう。メニュー名や配置はAccessのバージョンで異なる場合があります。
緑色のマーカーや警告ボタンが表示される場合は、その説明も手掛かりになります。ただし、警告が表示されない場合もあるため、警告の有無だけで正常かどうかを判断せず、設定内容を確認します。
関連記事：Access プロパティシートの使い方
ステップ4 コントロールソースを正しい項目に直す
［データ］タブの［コントロールソース］を確認します。この例では、テーブルT_顧客に「顧客ID」「顧客名」があり、クエリQ_顧客一覧が両方を出力し、フォームF_顧客がそのクエリを使う構成です。
| 確認項目 | 変更前 | 変更後 |
|---|---|---|
| フォームのレコードソース | Q_顧客一覧 | Q_顧客一覧（変更なし） |
| 対象部品の名前 | txt顧客名 | txt顧客名（変更なし） |
| コントロールソース | 顧客名称（存在しない） | 顧客名（クエリの出力項目） |
コントロールソースの候補から「顧客名」を選択します。手入力するときは、文字の違いや余分な空白に注意してください。ここで変更するのは表示先の設定であり、エラーに合わせて元テーブルの列名を変更する必要はありません。
目的のフィールドが候補に見当たらない場合は、似た名前の項目を適当に選ばず、次章のレコードソースの確認へ進みます。また、設定が「=」から始まる計算式なら、式全体をフィールド名で上書きせず、計算の目的を確かめてから修正しましょう。
関連記事：Access コントロールソースの使い方
ステップ5 保存してフォームビューで表示を確認する
フォームの設計を保存し、フォームビューに切り替えます。エラーが消えたかだけでなく、対象レコードに対応する顧客名が表示されているかを、クエリや元データと照合してください。別のフィールドを選んでしまっても、表示だけはできる場合があります。
複数のレコードに移動して、各顧客の値が正しく切り替わることも確認します。入力用の項目であれば、検証用データで変更・保存・再表示を確認しましょう。計算式による表示は、通常の連結項目と同じようにテーブルへ保存されるものではありません。
直らない場合はレコードソース・計算式・参照先を確認
正しい項目名に直しても解消しないときは、レコードソース、計算式、参照先の順に確認します。どの範囲でエラーが出ているかを先に整理すると、確認箇所を絞りやすくなります。
| 症状 | 優先して確認する箇所 | 確認する内容 |
|---|---|---|
| 1つの項目だけ | コントロールソース | 綴り、変更前のフィールド名、式 |
| 複数の項目に発生 | レコードソース | 使うクエリ、出力列、実行時の切り替え |
| 計算欄だけで発生 | 式と参照範囲 | 名前、自己参照、関数 |
| 別フォームの値で発生 | フォームへの参照 | 名前、開いている状態、サブフォーム構成 |
| 特定のPCだけ | ファイルと実行環境 | 配布版の違い、関数、参照ライブラリ |
候補に項目がない場合はクエリの出力列まで確認
デザインビューでフォーム全体を選択し、［データ］タブの［レコードソース］を確認します。クエリ名が設定されていれば、そのクエリを開き、出力される列を確かめてください。テキストボックスを選択した状態では、フォーム全体の設定を確認できません。
例えば、T_顧客には「顧客名」があっても、Q_顧客一覧が「顧客ID」しか出力していなければ、フォームが使うデータに顧客名が含まれません。単純な選択クエリなら、必要なフィールドを出力対象へ加える方法を検討できます。
SELECT [顧客ID], [顧客名] FROM [T_顧客];
これは説明用のSELECT例です。実際には、既存クエリの抽出条件や並び順を残して修正します。集計・結合・重複除外を使うクエリでは、列の追加で集計結果や更新可能性が変わることがあるため、上のSQLで丸ごと置き換えないでください。
クエリでフィールドに別名を付けている場合は、その出力名も確認します。フォームが受け取る名前とコントロールソースを合わせることがポイントです。ボタン操作やVBAでレコードソースを切り替えている場合は、エラーが出た時点の設定も調べます。
計算欄だけで発生する場合は式を分けて確認
計算欄では、式に含まれる名前を1つずつ確認します。例えば「数量」と「単価」を掛ける場合、次の式を使えますが、両方の名前がそのフォームから正しく参照できることが前提です。
=[数量]*[単価]
角括弧で囲むと名前の範囲を明確にできますが、存在しないフィールドを使えるようにするものではありません。元の式を控え、作業用コピーで参照を1つずつ確認すると、どこで解決できなくなっているかを調べやすくなります。
固定の文字を表示する式では、文字列を半角の二重引用符で囲みます。例えば次の式なら「確認済み」という文字を表示します。引用符なしで名前のように指定すると、意図しない参照として扱われる可能性があります。見出しだけが必要なら、ラベルの利用も検討しましょう。
=”確認済み”
さらに、計算欄が自分自身を参照していないかを確認します。部品名を「txt金額」のように区別する運用は、参照を読み解く助けになります。ただし、既存の部品名を変えるとVBAや他の式へ影響するため、関連箇所を調べてから変更してください。
名前や式の誤りは、状況によって#Errorなど別の表示になることもあります。#Name?と同じ原因だと決めつけず、実際に表示されている文字と式を記録して切り分けましょう。
別フォームやサブフォームの参照先を確認
別のフォームの値を使う式では、フォーム名と対象コントロール名に加え、そのフォームが開いているかを確認します。式の評価時点で参照先が利用できなければ、期待する値を取り出せません。起動時だけ発生する場合は、フォームを開く順序も手掛かりになります。
親フォームからサブフォーム内の値を読むときは、画面上に配置した「サブフォームコントロール」の名前と、その中で開くフォームの名前を区別します。次は、親フォームのテキストボックスに設定する式の例です。
=[sfrm受注明細].Form![txt合計]
この例のsfrm受注明細は、親フォームに配置したサブフォームコントロールの名前です。.Formを経由し、その内部のフォームにあるtxt合計を参照します。ナビゲーションウィンドウに表示されるフォーム名を、そのまま使えばよいとは限りません。
まず内部のフォームを確認し、txt合計自体が正常な値を表示しているかを確かめます。そのうえで親フォームからの参照を確認すると、内部の計算エラーと参照パスの誤りを分けて調べられます。上の名前は説明用なので、実際の部品名に合わせてください。
関数や特定PCだけで起きる場合は追加調査する
関数を使う欄だけで発生する場合は、関数名の綴りや呼び出す関数の存在を確認します。同じファイルが別PCでは動く場合は、配布ファイルの版、Access環境、利用するライブラリの違いも比較しましょう。
開発担当者は、VBEの［ツール］［参照設定］で「参照不可」「MISSING」などの表示を確認し、必要な参照先を解決します。Microsoftも、参照が未解決のままではコードを実行できないと案内しています。これは関数関連の追加調査であり、#Name?の原因がすべて参照切れという意味ではありません。
必要なライブラリを無条件に外すと、別の機能が動かなくなる場合があります。原因と影響が分からないときは、表示されたエラー、対象の式、環境情報をまとめて担当者へ引き継いでください。
設定を確認しても直らない場合はお気軽にご相談ください。フォームとクエリの関係、式やVBAの参照範囲を整理し、必要な調査・改修をご案内します。
修正後の確認と#Name?の再発防止
修正の完了は、#Name?が消えたことだけで判断しません。期待する項目が表示され、通常の入力やレコード移動で問題がないことまで確かめます。設定を変える前後で確認対象をそろえると、別の不具合にも気付きやすくなります。
表示と保存を分けて確認する
- 元データとフォームの表示値が一致しているか。
- 複数レコードで表示が正しく切り替わるか。
- 入力用の連結項目は、検証データで変更・保存・再表示ができるか。
- 計算欄は、入力値が変わったときに期待する結果になるか。
- 関連する画面・帳票・ボタン処理に影響がないか。
計算欄の表示値と、テーブルに保存する値は役割が異なります。エラーを直すために連結フィールドを計算式へ変えると、従来の入力方法が変わる可能性があります。元々「入力する欄」だったのか「計算結果を見る欄」だったのかを確認しておきましょう。
名称変更の前に参照している場所を調べる
フィールドやコントロールの名前を変えるときは、利用しているクエリ・フォーム・レポート・式・マクロ・VBAを確認します。特にフォームを複製した場合は、見た目が同じでも、以前のデータ元や名前への参照が残っていることがあります。
オブジェクトの依存関係は調査の手掛かりになりますが、VBAなどを含むすべての参照を網羅するとは限りません。検索や動作確認を組み合わせ、変更前後の設定と確認結果を残しておくと、次の保守が進めやすくなります。
関連記事：Access オブジェクトの依存関係の使い方
まとめ：参照先を順に確認し、原因が不明なら調査を依頼
Accessフォームの#Name?は、まず対象テキストボックスのコントロールソースと、フォームのレコードソースの出力項目を照合します。正しいフィールド名へ修正しても直らない場合は、計算式の名前、サブフォームの参照先、関数や実行環境を順に確認しましょう。
修正前にバックアップと変更前の設定を残し、修正後は表示値と必要な保存動作まで確認します。フォームの見た目だけでなく、どこから値を取り出しているかを理解することが、再発防止につながります。
フォームのエラーが直らない・変更の影響が分からない方へ
複数のフォームでエラーが出る、設計資料がなく参照先が分からない、業務を止めずに直したいといった場合は、お気軽にご相談ください。現在の症状とAccessの構成を確認し、原因調査と必要な改修をご案内します。
相談時は、フォーム名、対象コントロール名、表示されたエラー、両ソースの設定、直前の変更内容、Accessのバージョン・bit数をまとめると状況を伝えやすくなります。画面を共有する際は、顧客名などの業務情報を伏せてください。
よくある質問
表示だけでは、データが消えたとは判断できません。まず元のテーブルやクエリで対象レコードを確認します。元データが残っていても、フォームが誤った名前を参照していれば正しく表示できない場合があります。
警告の有無にかかわらず、対象テキストボックスのコントロールソースを確認します。表示形式やエラーチェックの状態に依存せず、プロパティの設定とレコードソースの出力列を照合する方法が基本です。
フォームのレコードソースを確認し、クエリが必要なフィールドを出力しているかを調べます。元テーブルに列があるだけでは十分とは限りません。クエリに別名を付けている場合は、その出力名も確認してください。
必ず同じにする必要はありません。名前は部品の識別、コントロールソースは表示するデータや式の指定です。連結コントロールで同名になることもありますが、計算欄では自己参照や読みにくい参照を避けるため、役割が分かる部品名に整理すると保守しやすくなります。
NzはNullを指定した値などに置き換える関数で、存在しない名前を修正する機能ではありません。先にフィールド名や参照先を直してください。その後、未入力を0として計算するなどの業務上の意味がある場合に、Nullの扱いを検討します。
参考情報
[1] Microsoft Learn｜TextBox.ControlSource property (Access)
コントロールに表示するフィールド・式と、フォームのデータ元との関係。
[2] Microsoft Learn｜Form.RecordSource property (Access)
フォームのデータ元として指定するテーブル・クエリ・SQL。
[3] Microsoft Learn｜TextBox.Name property (Access)
部品の名前と、連結コントロールに付く既定名。
[4] Microsoft Learn｜SubForm.Form property (Access)
サブフォームコントロール内のフォームへの参照。
[5] Microsoft Learn｜Can’t find project or library
未解決のライブラリ参照の確認と解決。
[6] Microsoft Learn｜Application.Nz method (Access)
Nullを別の値へ置き換えるNzの役割。