Accessクエリでフィールド名が重複する原因と解決法

概要

この記事でわかること

• フィールド名の重複でエラーになる原因と症状の切り分け
• デザインビューで参照元を指定する手順
• SQLの修正方法とテーブル別名・列別名の使い分け
• 修正後のデータとフォーム・帳票を確認するポイント

この記事の主な内容

1. フィールド名の重複は参照先と出力名に分けて考える
2. デザインビューでテーブル名を指定して直す
3. SQLビューで参照先を明示する
4. 出力列名の重複は別名で整理する
5. 直らないときと変更後に確認すること
6. 同じトラブルを防ぐクエリ設計と保守の考え方
7. まとめ
8. よくある質問

想定読了時間：約10分～約12分

1　フィールド名の重複は参照先と出力名に分けて考える

同じ名前のフィールドが複数のテーブルに存在すること自体は、異常ではありません。受注テーブルと顧客マスターの両方に「顧客ID」があるように、テーブルを結び付けるために同じ項目を持つ構成は一般的です。

ただし、そのクエリで単に[顧客ID]と書くと、Accessが参照するテーブルを特定できない場合があります。この状態と、結果の列名が重なる状態は、対処する箇所が異なります。

複数のテーブルを参照したというエラーの意味

「指定されたフィールドが、FROM句にある複数のテーブルを参照した」という趣旨のエラーは、使いたい列の名前だけでは参照元が決まらないことを示します。FROM句とは、クエリが読み取るテーブルなどを指定する部分です。

例えば、T_受注とM_顧客に顧客IDがあるとき、[T_受注].[顧客ID]と書けば受注側の列を特定できます。このようにフィールド名に参照元を付けることを「修飾」といいます。Microsoftも、同名のフィールドが複数テーブルにある場合の書き方として案内しています。

出力列名の重複とレコードの重複は別問題

参照元を指定しても、両方の顧客IDを結果へ出すなら、使う側が区別できる名前が必要です。「受注側顧客ID」「顧客マスターID」のように役割が伝わる別名を付けると、後続処理での取り違えを防ぎやすくなります。

一方、同じ顧客の行が複数出る現象は列名とは別です。顧客に対して複数の受注があれば、結合後に複数行になることがあります。列名の変更では解消しないため、結合条件と表示したい単位を確認しましょう。

2　デザインビューでテーブル名を指定して直す

デザインビューでは、計算式の中で使っているフィールドにテーブル名を付けて修正します。最初に元のクエリをコピーし、業務用のクエリに影響しない状態で確認してください。

修正前にクエリをコピーする

ナビゲーションウィンドウで対象クエリを選択し、コピーして別名で貼り付けます。例えば「Q_受注一覧_確認用」のように、確認用と分かる名前にします。元のSQLも控えておくと、変更箇所を比較できます。

コピーしたクエリを右クリックし、デザインビューで開きます。本記事の対象はデスクトップ版Accessの通常の選択クエリです。更新・削除・追加クエリや、SQL Serverへ送るパススルークエリは、同じ手順で実行しないでください。

参照するテーブルとフィールドを確認する

上段のフィールド一覧で、重複している名前がどのテーブルにあるかを確認します。下段のデザイングリッドで通常のフィールドを選ぶ場合は、［テーブル］行も確認してください。計算式の内部では、参照元を式に明記すると読み間違いを防げます。

以降は、説明用の架空データを使います。T_受注の顧客IDとM_顧客の顧客IDを、値が一致する行どうしで結合する構成です。

顧客IDは両方とも数値型の長整数とし、M_顧客では主キーにします。受注番号と顧客名は短いテキスト型です。T_受注の受注IDはオートナンバー型の主キーとします。

計算式にテーブル名を付ける

受注番号と顧客IDをつなぐ計算列で、次のように顧客IDの参照元が省略されていると、どちらのテーブルの値か判断できません。下記はデザイングリッドの［フィールド］行に入力する式です。

受注明細: [受注番号] & ” / ” & [顧客ID]

受注側の顧客IDを使いたい場合は、次のように修正します。受注番号も修飾しておくと、どこから値を取り出す式なのかが明確になります。

受注明細: [T_受注].[受注番号] & ” / ” & [T_受注].[顧客ID]

角括弧でテーブル名とフィールド名を別々に囲み、その間を半角のドット「.」でつなぎます。「受注明細:」は計算列の名前、&は値をつなぐ演算子です。コロンや引用符も半角で入力します。

データシートで値を確かめる

データシートビューに切り替え、列の値を確認します。上記データなら「ORD-001 / 101」「ORD-002 / 102」と表示される想定です。エラーが消えたことだけでなく、意図した受注番号と顧客IDになっているかを見てください。

確認後は保存して開き直し、同じ結果になることも確かめます。結果が異なる場合は、参照元に加えて結合線や抽出条件に変更がないかを確認しましょう。

3　SQLビューで参照先を明示する

SQLビューでは、曖昧なフィールド参照を見つけてテーブル名を付けます。SQLはクエリの処理内容を文字で表したもので、選ぶ列、読み取るテーブル、条件などをまとめて確認できます。

SELECTと計算式の参照を修正する

確認用クエリを開き、［表示］からSQLビューへ切り替えます。次の例では、SELECTの顧客IDだけに参照元がありません。ONで結合先を指定していても、SELECTに書いた顧客IDの参照元まで決まるわけではありません。

SELECT [顧客ID]
FROM [T_受注] INNER JOIN [M_顧客]
ON [T_受注].[顧客ID] = [M_顧客].[顧客ID];

受注側の顧客IDを取り出すなら、SELECTでも[T_受注].[顧客ID]と書きます。次の例は、受注番号と顧客名も出力し、顧客IDが101の受注に絞っています。

SELECT [T_受注].[受注番号],
      [T_受注].[顧客ID], [M_顧客].[顧客名]
FROM [T_受注] INNER JOIN [M_顧客]
ON [T_受注].[顧客ID] = [M_顧客].[顧客ID]
WHERE [T_受注].[顧客ID] = 101
ORDER BY [T_受注].[顧客ID], [T_受注].[受注番号];

このデータ例では、ORD-001、101、青葉商店の1行が返る想定です。顧客IDを数値型としているため、101を引用符で囲んでいません。実際のデータ型に合わせて条件を書き換えてください。

WHEREとORDER BYも確認する

SELECTを直しても解消しない場合は、抽出条件を表すWHEREや、並べ替えを表すORDER BYにも同名フィールドがないか確認します。集計クエリであれば、GROUP BYやHAVINGの式も確認対象です。

ただし、見つけたフィールドをすべて同じテーブルへ機械的に置き換えるのは避けましょう。その式が受注側の値を使うのか、顧客マスター側の値を使うのかを、処理の目的から判断します。

テーブルに別名を付ける場合

長いテーブル名は、FROM句で短い別名を付けるとSQLが読みやすくなります。例えばT_受注をO、M_顧客をCとした場合は、参照もO.[顧客ID]、C.[顧客ID]に統一します。

テーブル別名は、そのSQL内で参照元を呼ぶための名前です。元テーブルの名前を変更する操作ではありません。具体的なSQLは、次の列別名の例で示します。

4　出力列名の重複は別名で整理する

出力列名が重複する場合は、それぞれに異なる別名を付けます。参照元の指定は「どの値か」、列の別名は「その値を何という名前で出すか」を決める操作です。必要に応じて両方を指定します。

デザイングリッドでは別名と式をコロンで区切る

テーブル別名を付けていない確認用クエリなら、［フィールド］行に次のように入力します。受注側の顧客IDを、「受注側顧客ID」という列名で出力する指定です。

受注側顧客ID: [T_受注].[顧客ID]

顧客マスター側も出す場合は、別の列へ次の式を入力します。元テーブルの列名はそのままで、クエリの出力名を区別できます。

顧客マスターID: [M_顧客].[顧客ID]

SQLではASで出力名を指定する

SQLでは、式の後にASと別名を書きます。MicrosoftのSELECT文の説明でも、返されるフィールドに別の名前を付ける方法としてASが示されています。［1］

SELECT O.[受注番号],
      O.[顧客ID] AS [受注側顧客ID],
      C.[顧客ID] AS [顧客マスターID], C.[顧客名]
FROM [T_受注] AS O INNER JOIN [M_顧客] AS C
ON O.[顧客ID] = C.[顧客ID]
ORDER BY O.[受注番号];

この例のOとCはテーブル別名、受注側顧客IDと顧客マスターIDは列別名です。前章のWHERE条件は付けていないため、サンプルの受注2行を出力します。

修飾と別名を使い分ける

未修飾の[顧客ID]にASを付けるだけでは、どちらのテーブルの顧客IDなのかという曖昧さは残ります。また、別々の出力列に同じ別名を付けると、利用先で区別しにくくなります。

5　直らないときと変更後に確認すること

参照元を指定しても直らない場合は、名前の誤記と、クエリから参照できる範囲を確認します。修正できた場合も、結果の値とそのクエリを使っている処理を確認してから本番へ反映しましょう。

名前の誤記と別名の混在を確認する

• テーブル名・フィールド名に全角と半角、スペース、文字の違いがないか
• FROM句でOなどの別名を付けた後も、元のテーブル名で参照していないか
• 修正したつもりのSQLと、実際にフォームが利用するクエリが一致しているか
• 元データが別の保存クエリの場合、そのクエリが必要な列を出力しているか

例えば、Q_受注一覧を元に新しいクエリを作る場合は、Q_受注一覧が外へ出しているフィールドを参照します。内部で使われているT_受注を、外側のクエリから直接参照できるとは限りません。階層ごとに出力列を確認します。

修正後に意図しないパラメーター入力が出る場合も、存在しない名前や古い参照名が残っていないかを調べます。もともと入力を求めるように設計されたパラメーターなら正常なため、表示された名前とクエリの仕様を照合してください。

結合条件とNullを確認する

受注側と顧客側の顧客IDは、いつでも交換できるわけではありません。ここまでのINNER JOINでは、結合条件を満たす行だけを表示しています。受注をすべて残すLEFT JOINでは、相手の顧客が見つからない行も残せます。

例えば、受注側に999という顧客IDがあり、顧客マスターに該当行がない場合、左側の値は999でも、右側の顧客IDはNullになります。Nullは値がない状態です。この場合に参照先を右側へ変えると、表示される値の意味も変わります。

エラー修正の際は、結合方法や抽出条件を同時に変更せず、どの修正が結果に影響したか分かる状態にします。行が増えた場合も、DISTINCTで隠す前に、必要な受注行が失われないかを確認してください。

フォームと帳票への影響を確認する

出力列の名前を変えると、その名前を使うフォームや帳票、後続クエリを直す必要が生じることがあります。見た目の列見出しだけでなく、処理が参照するフィールド名として使われていないかを確認します。

オブジェクトの依存関係は影響調査の入口として使えます。ただし、それだけでVBA内のSQL文字列や外部処理まで確認できたとは考えず、コードと実際の業務操作も確認しましょう。

クエリ修正の影響範囲が分からない場合はご相談ください

参照するクエリが多段化している場合や、修正が複数の画面・帳票に及ぶ場合は、原因調査と影響確認をまとめて進めることが大切です。既存Accessのクエリや参照エラーに関する保守・改修のご相談を承っています。

6　同じトラブルを防ぐクエリ設計と保守の考え方

再発を防ぐには、参照元と出力名を読み手が追える状態にそろえます。エラーが出た箇所だけでなく、そのクエリを使う処理まで含めて名前の役割を整理すると、変更時の確認がしやすくなります。

必要な列を明示し出力名を安定させる

複数テーブルを結合する業務用クエリでは、必要なフィールドを個別に選ぶ運用をおすすめします。SELECT *は便利ですが、テーブルに列を追加したとき、クエリの出力項目も意図せず変わる可能性があります。

また、「ID1」「ID2」のような順番だけの名前より、「受注側顧客ID」のように役割が分かる名前を使いましょう。出力列名はフォームや帳票との接点になるため、変更する場合は利用先もセットで確認します。

元テーブルのフィールド名変更は影響調査後に行う

同名フィールドの参照エラーだけなら、まずクエリ側で修飾や別名を指定します。元テーブルのフィールド名を変更すると、既存のクエリ・フォーム・帳票・コードにも影響が広がる可能性があるためです。

命名規則そのものを整理する場合は、参照先の一覧、修正内容、確認結果を記録します。名称の自動修正が働く環境でも、すべての参照が自動で直ることを前提にせず、変更後の確認を行ってください。

専門会社へ相談する目安

単純な未修飾参照なら、本記事の手順で解決できることがあります。一方、引継ぎ資料がない、修正するたびに別の帳票が止まる、日常業務への影響が大きいといった場合は、全体の参照関係を調べるところから進めるのが確実です。

エラー画面、対象クエリ名、SQL、発生する操作、直前の変更内容をそろえると、相談時に状況を伝えやすくなります。フィールド名の重複だけを理由に、全面的なシステム移行を急ぐ必要はありません。

まとめ

Accessクエリのフィールド名重複は、まず参照先が曖昧なのか、出力列名が重なっているのかを切り分けます。参照先にはテーブル名やテーブル別名を付け、出力列は用途の分かる別名で整理しましょう。

修正後はエラーの有無だけでなく、データの値・件数と、フォーム・帳票・後続処理への影響を確認します。元テーブルを安易に変更せず、確認用のコピーで修正内容を確かめてから反映することが大切です。

既存Accessのクエリと参照エラーをご相談ください

既存Accessの保守・改修に対応しておりますので、クエリのエラー原因が分からない場合や、画面・帳票を含めた影響調査が必要な場合は、現在の構成と症状をお知らせください。状況に合わせて修正範囲を整理します。

よくある質問

参考情報

［1］Microsoft Learn「SELECT statement (Microsoft Access SQL)」
https://learn.microsoft.com/en-us/office/client-developer/access/desktop-database-reference/select-statement-microsoft-access-sql