概要
| この記事の結論 Accessでテーブルのフィールドが削除できないときは、まずエラーメッセージを確認します。リレーションシップが原因なら、バックアップと使用箇所の確認を済ませ、不要と判断した関係を削除してからフィールドを削除します。リンクテーブルや使用中・読み取り専用の場合は確認先が異なるため、関係線を消すだけでは解決しません。 本記事では、列を削除できない原因の見分け方と操作手順を解説します。対象はWindows版Accessのデスクトップデータベースです。画面の名称や配置はAccessのバージョンによって異なることがあります。 |
この記事でわかること
- エラーメッセージから原因と確認先を見分ける方法
- リレーションシップを削除する前に調べること
- 関係が原因の場合にフィールドを削除する手順
- リンクテーブルや使用中の状態で設計変更できない場合の対処
- 削除後の動作確認と、削除を保留する判断基準
この記事の主な内容
- フィールドが削除できないときはまずエラーと対象を確認する
- 削除前にバックアップとフィールドの使用箇所を確認する
- リレーションシップが原因で削除できない場合の対処手順
- 関係線が見つからない場合や設計変更できない場合の確認先
- 削除後の動作確認と削除を保留すべきケース
- フィールド削除でよくある質問とまとめ
想定読了時間：約10分～約12分
1 フィールドが削除できないときはまずエラーと対象を確認する
削除できない原因を調べるには、表示されたエラーの内容と、操作しているテーブルを確認することが出発点です。「削除できない」という症状だけで、リレーションシップが原因だと決めつけないようにしましょう。
フィールドは列でレコードは行
フィールドの削除とは、テーブルの列の定義と、その列に保存されたデータを取り除く操作です。例えば「電話番号」フィールドを削除すると、各レコードに登録された電話番号も利用できなくなります。不要な顧客のレコードを1件削除する操作とは異なります。
また、クエリの出力項目からフィールドを外す操作では、元のテーブルの列は残ります。ただし、そのクエリから値を取得しているフォームやレポートには影響するため、出力項目の整理にも使用箇所の確認が必要です。
エラー別に確認先を分ける
リレーションシップに関するメッセージが表示された場合は、対象フィールドを使う関係を調べます。一方、設計変更そのものができない場合は、リンク先や利用状態も確認しましょう。次の表はメッセージの要旨と確認先を整理したものです。
| 症状やメッセージの要旨 | 主な確認先 | 最初の対応 |
|---|---|---|
| フィールドに関係が設定されている | リレーションシップ | 対象フィールドにつながる関係を確認 |
| リンクテーブルの構造を変更できない | 実データがあるリンク元 | リンク元の種類と管理者を確認 |
| テーブルや関係が使用中になっている | 自分の画面や他の接続 | 関連する画面・処理を終了 |
| 読み取り専用などで保存できない | 開き方・ファイル・権限 | 読み取り専用の理由を確認 |
| 削除後に画面や処理でエラーが出る | 残っているフィールド参照 | 影響箇所を修正し動作確認 |
最後の行は、削除を阻止する原因ではなく、削除した後に生じる問題です。エラー文、テーブル名、フィールド名、実行した操作を記録すると、原因の切り分けや担当者への相談が進めやすくなります。
2 削除前にバックアップとフィールドの使用箇所を確認する
削除操作の前に、復元できるバックアップと、対象フィールドを使う処理の一覧を用意します。「今の画面に表示されていない」という理由だけでは、未使用とは判断できません。過去の帳票や月次処理で使っている可能性も確認しましょう。
データを含むバックアップを用意する
Accessファイルをコピーして退避する場合は、利用者と処理の終了を確認してから行います。ファイル名には作業日などを付け、変更前の版を識別できるようにしてください。退避先のコピーが開けるか、必要なデータが含まれるかも確認します。
分割データベースでは、画面や処理を持つフロントエンドと、テーブルを保存するバックエンドが分かれています。フロントエンドだけを保存しても、リンク先の列データは退避できません。SQL Serverなどが保存先の場合は、管理者とバックアップ・復元方法を決めておきます。
検証用にフロントエンドをコピーしただけでは、リンクが本番データを指したままのことがあります。テストを始める前に接続先を確認し、コピーしたバックエンドなどの検証用データへ切り替えてください。バックアップの詳しい手順は、関連記事「ACCESS バックアップを取る方法」も参照してください。
依存関係から使用箇所を調べる
まず、ナビゲーションウィンドウで対象テーブルを選び、［データベースツール］の［オブジェクトの依存関係］を確認します。関連するクエリやフォームなどを手掛かりに、削除予定のフィールドが使われているかを調べます。
保守作業では、この確認に加えて、クエリの抽出条件や並べ替え、フォーム・レポートのコントロールソース、VBA内のSQL、マクロ、外部への出力項目も点検します。依存関係の画面に何も出ないことだけで、影響がないと判断しないことが大切です。
例えば、通常の入力画面では使わなくなった「旧担当ID」が、過去実績の帳票で必要な場合があります。対象のオブジェクト名、使用目的、修正内容、確認担当を一覧にし、利用箇所を修正するか、データを残すかを決めましょう。
3 リレーションシップが原因で削除できない場合の対処手順
対象フィールドにリレーションシップが設定されている場合は、関係の必要性を確認してから削除します。その後、テーブルのデザインビューで対象フィールドを削除します。ここからの手順は、バックアップと影響調査が完了した検証用データベースで進めてください。
リレーションシップと参照整合性の役割を理解する
リレーションシップは、テーブル間の対応するフィールドを関連付ける設定です。主キーはレコードを識別するための項目で、別のテーブルからその値を参照する項目を外部キーと呼びます。例えば、担当者のマスターと受注を担当IDで関連付ける構成があります。
参照整合性は、存在しない担当者のIDを受注へ登録するような不整合を防ぐ仕組みです。有効になっている関係を削除すると、その関係による保護も失われます。必要な関係であれば、フィールドの削除自体を見直してください。
| 操作 | 主に変わるもの | 注意点 |
|---|---|---|
| 関係線を削除する | テーブル間の関連付け | 有効だった参照整合性の保護も失う |
| フィールドを削除する | 列の定義と列内のデータ | 利用する画面や処理にも影響する |
| レコードを削除する | 対象の行データ | 連鎖削除の設定によって関連行にも影響 |
「レコードの連鎖削除」は行データを削除する際の設定です。フィールドを削除できるようにするために有効化するものではありません。また、参照整合性のチェックを外す操作と、関係そのものの削除も区別しましょう。
手順1 対象の関係と設定内容を確認する
［データベースツール］→［リレーションシップ］を開き、［すべてのリレーションシップ］など、すべての関係を表示する機能を選びます。削除したいフィールドにつながる線を探し、両側のテーブル名とフィールド名を確認してください。
説明用の例として、「T_受注」の「旧担当ID」を廃止する場合を考えます。この列が「M_担当」の「担当ID」と関連付けられていれば、その線が調査対象です。マスター側の担当IDまで削除する必要があるわけではありません。
対象線をダブルクリックして設定を開き、対応する項目、参照整合性、連鎖更新・連鎖削除などを記録します。複数の関係がある場合は一つずつ確認し、廃止する項目に必要な変更だけを整理します。確認だけであれば設定を変更せず閉じてください。
手順2 不要と判断した関係を削除する
対象線をクリックし、選択状態になっていることを確かめてDeleteキーを押します。確認メッセージが出た場合は、対象に誤りがないことを確認して進めます。線の選択と、テーブルの表示枠の選択を取り違えないようにしましょう。
関係の画面からテーブルを非表示にするだけでは、関係を削除したことにはなりません。また、関係を削除できないときは、そのテーブルを使うフォームや他の利用者の接続が残っていないか確認します。無関係な線をまとめて削除する操作は避けてください。
手順3 デザインビューでフィールドを削除して保存する
リレーションシップ画面を閉じ、ナビゲーションウィンドウで対象テーブルを右クリックして［デザインビュー］を開きます。削除予定のフィールドの行全体を選択し、Deleteキー、または［行の削除］を実行します。[1][2]
ここで選択する「行」は、テーブルの設計画面に並ぶフィールド定義の行です。データシートビューのレコード行とは異なります。データ消失に関する確認が出たら内容を読み、予定どおりの場合にのみ進め、テーブルを保存して閉じます。
なお、クエリのJOINは、検索時にテーブル同士を結び付ける指定です。リレーションシップ画面の設定と同一ではありません。関係線を削除しても既存クエリのJOINやフィールド参照が自動的に不要になるわけではないため、事前に整理した修正箇所を確認します。
4 関係線が見つからない場合や設計変更できない場合の確認先
関係線が見えないときは表示範囲を、設計変更ができないときは保存先と利用状態を確認します。別の原因がある状態で関係線を消しても、目的の列を削除できるとは限りません。
すべての関係と非表示オブジェクトを確認する
リレーションシップ画面には、必要なテーブルが表示されていない場合があります。まず、すべての関係を表示します。それでも見つからなければ、ナビゲーションオプションの非表示オブジェクトの表示設定も確認してください。
続いて、開いているファイルが想定したデータベースか、対象がローカルテーブルかリンクテーブルかを調べます。別のバックエンドにあるテーブルなら、その保存先で関係を確認する必要があります。
リンクテーブルは実データがある保存先で変更する
リンクテーブルは、別のデータベースにあるテーブルを参照する仕組みです。Accessファイル同士のリンクでは、リンクを利用する側でフィールドの追加・削除やデータ型変更はできません。データを編集できても、構造まで変更できるとは限らない点がポイントです。
リンク元がAccessなら、そのバックエンドを管理する担当者と変更を進めます。SQL Serverなどがリンク元なら、データベース管理者に、削除予定の列と利用箇所を伝えてください。必要な権限や制約、他システムへの影響を確認し、リンク元で構造を変更します。
変更後は、必要に応じてリンク情報を更新・再作成し、Access側のクエリやフォームも確認します。リンクを削除して作り直すだけでは、リンク元の列自体は削除されません。
使用中の画面や処理を閉じる
対象テーブルを使うフォームや処理が開いていると、関係を削除できないことがあります。自分の画面だけでなく、他の利用者や定期処理からの接続も確認してください。Microsoftも、関係に含まれるテーブルが使用中の場合は、使用するオブジェクトを閉じるよう案内しています。[3]
共有運用では作業時間を調整し、全員の終了を確認してから再試行します。必要に応じて排他モードで開きますが、排他モードは他の利用者を強制的に切断する機能ではありません。詳しい開き方は「ACCESSを排他モードで開く方法」を参照してください。
読み取り専用と変更権限を確認する
読み取り専用で開いていないか、ファイルの属性や保存先のアクセス権で書き込みが制限されていないか確認します。会社が管理する場所の権限は、自己判断で広げず管理者に確認しましょう。Access Runtimeでは設計機能を利用できないため、設計変更は製品版Accessを持つ担当者へ依頼します。
また、主キーやインデックス、ルックアップに関するメッセージがある場合は、その設定と関係を調べます。主キーの変更は他のテーブルや連携先に影響するため、単に削除するためだけに外さないでください。解消しない場合は、メッセージを省略せず記録して調査します。
ロック情報を持つlaccdbファイルの強制削除や、警告の無効化は、原因を確認する代わりにはなりません。作業中の利用者がいる状態で強制終了させる対応も避け、接続の終了と保存先の確認を先に行います。
5 削除後の動作確認と削除を保留すべきケース
フィールドの削除が完了したら、実際の業務の流れで動作を確認します。テーブルが保存できただけでは、変更作業は完了していません。事前に調べた使用箇所を一つずつ確認し、修正漏れがないかを確かめます。
入力から出力までを確認する
| 確認対象 | 実施する操作 | 見るポイント |
|---|---|---|
| フォーム | 起動・入力・編集・保存 | 参照エラーや保存失敗がない |
| クエリ | 検索・集計・並べ替え | 不要なパラメーター入力が出ない |
| レポート | プレビュー・印刷・PDF出力 | 項目や集計値が想定どおり |
| VBA・マクロ | ボタン操作・定期処理 | 列を参照する処理に修正漏れがない |
| 外部連携 | CSV出力・取込・他システム接続 | 項目名・列順・件数が想定どおり |
削除した列を参照するコントロールでは「#Name?」などが表示されることがあります。また、クエリに旧フィールド名が残っていると、意図しないパラメーター入力を求められる場合もあります。警告を閉じて使い続けず、コントロールソースやクエリの定義を見直しましょう。
復元と利用再開の条件を決める
検証で異常が見つかったら、利用再開を保留し、修正またはバックアップからの復元を判断します。データベース全体を以前の状態に戻すと、バックアップ後の入力が失われる場合があります。復元範囲と追加データの扱いを確認してから実行してください。
検証用で問題がなくても、本番の変更直前にバックアップを取得し、同じ手順と確認項目で進めます。変更日、対象フィールド、関係の変更内容、確認結果を記録すると、後日の問い合わせや追加改修でも経緯を追えます。
削除する目的を再確認する
画面を見やすくしたいだけなら、列やコントロールの非表示で目的を達成できる場合があります。過去のデータを参照する必要があるなら、新規入力を止めつつデータを残す設計も選択肢です。非表示はアクセス権の制御ではないため、情報保護とは分けて考えてください。
仕様書がない、担当者が不在、外部連携への影響を調べきれない場合は、削除を保留して調査を進めましょう。インフォースの保守提案では、まず利用箇所と必要な機能を整理し、項目を廃止する範囲と順序を検討します。
削除してよいフィールドか判断できない場合はご相談ください
インフォースでは、既存Accessのテーブル・クエリ・フォーム・帳票などを確認し、変更の影響範囲と対応方針を整理します。引き継いだシステムの仕様が分からない場合も、確認できる資料やファイルの状況からご相談ください。
6 フィールド削除のまとめ
Accessのフィールドが削除できないときは、エラー文を確認し、関係設定・リンク元・使用中の状態・権限を切り分けます。関係が原因なら、バックアップと影響調査を済ませ、不要と判断した関係を削除してからフィールドを削除してください。
削除後は、画面入力から帳票や外部連携までを確認します。使用箇所が分からない場合は、無理に削除せず、非表示や利用停止も含めて整理方法を検討しましょう。
既存Accessの項目整理や設計変更でお困りの際は、お気軽にご相談ください。利用箇所の調査から、必要な改修と動作確認の範囲を整理します。
よくある質問
関係線の削除自体では、テーブルの列やレコードは削除されません。ただし、有効だった参照整合性による保護は失われます。その後にフィールドを削除すれば、その列のデータも失われるため、二つの操作を区別してください。
すべてのリレーションシップを表示し、非表示オブジェクトも確認します。さらに、対象がリンクテーブルであればリンク元のデータベースを確認してください。エラーの内容が関係以外を示している場合は、使用中の状態や権限を調べます。
参照整合性を無効にしても、リレーションシップそのものを削除したことにはなりません。関係があることを理由に削除が阻止されている場合は、必要性を判断したうえで対象の関係を削除する手順を確認します。
元に戻す操作で必ず復旧できるとは考えず、バックアップからの復元を準備してください。同じ名前の列を作り直しても、削除前の値は自動では戻りません。復元時はバックアップ取得後の入力データも確認します。
必要とは限りません。表示の整理であれば、列やフォーム上のコントロールを非表示にする方法があります。データの保存目的と使用箇所を確認し、表示だけを変えるか、項目自体を廃止するかを決めましょう。
あわせて読みたい記事
- 「Accessのテーブルとは」
- 「ACCESS バックアップを取る方法」
- 「ACCESS オブジェクトの依存関係の使い方」
- 「ACCESS フォームで#Name?と表示されるときの対処法」
- 「ACCESSを排他モードで開く方法」
参考情報
[1] Microsoft Support｜Delete a field
https://support.microsoft.com/en-us/access/delete-a-field
[2] Microsoft Support｜Add or delete a column in a datasheet
https://support.microsoft.com/en-us/access/add-or-delete-a-column-in-a-datasheet
[3] Microsoft Support｜Create, edit or delete a relationship
https://support.microsoft.com/en-us/access/create-edit-or-delete-a-relationship
[4] Microsoft Support｜Guide to table relationships
https://support.microsoft.com/en-us/access/guide-to-table-relationships
[5] Microsoft Support｜Import or link to data in another Access database
https://support.microsoft.com/en-us/access/import-or-link-to-data-in-another-access-database