概要
| この記事の結論 Accessの更新クエリは、指定した条件に合うレコードの値をまとめて変更し、その処理を保存して再利用する機能です。毎日の置換を定型化できますが、実行後は通常の元に戻す操作では取り消せません。まずExcelのPower Query等による変換や、保存値を変えずに表示する方法と比較し、更新が必要な場合は対象確認、バックアップ、結果照合を一組の手順にします。 |
この記事でわかること
- 置換と更新と表示変換を使い分ける
- 変更前に対象と復元手段を確定する
- 選択クエリで更新結果を予告する
- 更新クエリへ切り替えて実行する
- 繰り返し実行と部分置換の事故を防ぐ
この記事の主な内容
- 置換と更新と表示変換を使い分ける
- 変更前に対象と復元手段を確定する
- 選択クエリで更新結果を予告する
- 更新クエリへ切り替えて実行する
- 繰り返し実行と部分置換の事故を防ぐ
- 更新できない場合と誤更新時の対処
- 定型処理を業務として管理する
- よくある質問
想定読了時間：約15分～20分
置換と更新と表示変換を使い分ける
保存されている値を直したいのか、集計や出力時の見え方だけを変えたいのかを最初に決めます。毎日届くCSVの表記を統一するだけなら、元データを残したまま別の列へ変換結果を作る方法が扱いやすい場合があります。すべてを一括上書きする必要はありません。
Excelでは検索と置換のほか、Power Queryで取込・置換手順を保存して繰り返す方法もあります。Accessでも選択クエリの計算列や対応表との結合で、元の値を変更せず統一した名称を表示できます。保存値自体の訂正が必要な場合に、更新クエリを選びましょう。
| 目的 | 適した方法 | 元の保存値 |
|---|---|---|
| 一度だけ文言を直す | Excelの置換や個別修正 | 変更する |
| 毎日CSVを整形する | Power Queryや一時取込表の変換 | 元CSVを残せる |
| 表示用の名称をそろえる | 選択クエリ・変換マスター | 変更しない設計が可能 |
| 本番データを条件付きで訂正 | Accessの更新クエリ | 対象行を上書きする |
顧客名の変更では、同姓同名や同じ略称に注意します。「田中商店」をすべて変更するという処理より、確認した顧客IDに対して変更する方が対象を限定できます。名称変更と別会社への付け替えは意味が違うため、単純な文字列置換で同一視しないでください。
変更前に対象と復元手段を確定する
更新クエリを実行する前に、対象範囲と復元方法を決めます。Microsoftも、同じ条件の選択クエリで対象を確認し、バックアップを保つことを案内しています。［参考1］
「元に戻すボタンを押せばよい」という前提では運用しません。
今回の架空例は、T_取込明細の区分を「旧A」から「標準A」へ直す処理です。明細IDはオートナンバー型の主キー、取込バッチは短いテキスト型、区分は短いテキスト型、処理済はYes/No型で既定値Falseとします。取込バッチは、どの取込作業で入った行かを識別するための値です。
| 確認事項 | 具体的に残す内容 |
|---|---|
| 変更対象 | 対象テーブル・項目・取込バッチ・更新前の条件 |
| 想定件数 | プレビューで確認した件数と対象ID |
| 復元材料 | 更新直前のバックアップ、変更前の値 |
| 実行環境 | 本番か検証か、データの実際の保存先 |
| 作業時間 | 他の入力や取込を止められる時間 |
フロントエンドをコピーしただけでは、リンク先のデータは保護できません。テーブルが別ACCDBやSQL Serverにある場合は、その実データ側のバックアップが必要です。また共有利用中のACCDBを単純にコピーするのではなく、全員の利用を終了するなど整合したバックアップを取れる手順を決めます。
更新後に他の人が新しい取引を登録すると、バックアップ全体を戻すことで正しい追加分まで失うおそれがあります。作業中の更新停止、対象IDと変更前値の記録、復旧担当者を事前に決めておくと、誤更新が起きた場合にも影響を限定して判断できます
選択クエリで更新結果を予告する
最初に作るのは更新クエリではなく、変更前と変更後を並べた選択クエリです。これならデータを書き換えずに、対象行が正しいか確認できます。取込バッチは「B20261025A」、区分は旧A、処理済はFalseという三つの条件をすべて満たす行だけを表示します。
SELECT [明細ID], [取込バッチ],
[区分] AS [変更前],
“標準A” AS [変更後], [処理済]
FROM [T_取込明細]
WHERE [取込バッチ] = “B20261025A”
AND [区分] = “旧A”
AND [処理済] = False
ORDER BY [明細ID];
［作成］からクエリデザインを開き、SQLビューへ切り替えて貼り付け、Q_区分更新前確認として保存します。結果は変更前と変更後が別列に見えるだけで、保存値は変わりません。更新予定の件数と代表行を確認し、想定と違う行が一つでもあれば条件を修正します。
| 明細ID | 取込バッチ | 区分 | 処理済 | 今回の対象 |
|---|---|---|---|---|
| 1 | B20261025A | 旧A | False | 対象 |
| 2 | B20261025A | 旧B | False | 対象外 |
| 3 | B20261024A | 旧A | False | 対象外 |
| 4 | B20261025A | 旧A | True | 対象外 |
| 5 | B20261025A | 旧A | False | 対象 |
このテストの期待件数は2件、対象IDは1と5です。区分の条件だけでは前日分も入り、バッチだけでは旧Bや処理済の行も入ります。「フィルターをかけた画面で実行したから安全」ではなく、更新クエリ自体のWHERE条件で対象が限定されているかを確かめます。
更新クエリへ切り替えて実行する
確認用クエリを残し、別の更新クエリを作成します。デザインビューなら、T_取込明細を追加し、［更新］へ切り替えます。区分の［レコードの更新］に「標準A」、処理済の同じ行にTrueを指定し、取込バッチ・区分・処理済の抽出条件を確認用と一致させます。
UPDATE [T_取込明細]
SET [区分] = “標準A”, [処理済] = True
WHERE [取込バッチ] = “B20261025A”
AND [区分] = “旧A”
AND [処理済] = False;
Q_区分更新として保存し、検証用データベースで実行します。確認メッセージに示される対象件数を、先ほどの2件と照合します。実行後はID1と5が標準A、処理済=Trueになり、ID2から4は変わらないことを調べます。更新クエリは結果一覧を返さないため、確認は別の選択クエリで行います。［参考1］
プレビューから実行までの間に他の処理が行を書き換えると、対象が変わる場合があります。少人数の定型作業なら、対象バッチへの取込と修正を一時停止してから実行する方法が分かりやすくなります。競合が避けられない業務では、トランザクションや更新前値の照合などを含む設計が必要です。
警告を消すことを最初の目的にしないでください。VBAで実行する場合は、DAOのQueryDefとパラメーターで対象を渡し、dbFailOnError、エラー処理、更新件数の確認を組み合わせる方法があります。ただしdbFailOnErrorは、正常終了した後に好きな時点へ戻せる機能ではありません。復元用の材料は別に必要です。
Accessの教科書で置換業務の改善を相談する
候補や集計条件が部署ごとに異なる、既存の画面を直せる担当者がいないなど、置換の手順だけでは解決しない場合は、現在のExcelと業務の流れを整理して相談すると検討が進みます。Accessの教科書のお問い合わせで、対象データ、利用人数、困っている操作をお知らせください。
繰り返し実行と部分置換の事故を防ぐ
同じ処理を二回実行しても結果が変わらない性質を、冪等性と呼びます。今回の例は、旧Aかつ未処理の行だけを標準Aへ変えるため、同じ対象へ再実行したときの更新件数は原則0件になります。バッチ単位で条件を固定することで、翌日の新しいデータと混ざることも防ぎやすくなります。
一方、「金額を1.1倍する」「名称の先頭に文字を付ける」更新は、再実行するとさらに値が変わります。元金額から計算し直す、処理対象を未処理だけにする、実行履歴と業務キーで二重処理を防ぐなどの設計が必要です。処理済フラグだけでは、同じCSVを別レコードとして二重取込した問題までは防げません。
| 処理 | 再実行時の注意 | 対策 |
|---|---|---|
| 旧Aを標準Aへ完全一致で変更 | 旧Aが残っていなければ0件 | 旧値とバッチを条件にする |
| 金額を1.1倍する | 再度1.1倍される | 元金額を保持して再計算 |
| 名称に接頭辞を付ける | 接頭辞が重なる | 元名称から結果を作る |
| 文字の一部をReplaceで変更 | 別の単語にも影響する | 対象列・条件・変更後を先に確認 |
部分置換では、AccessのReplace関数を使えます。例えば「Replace([区分],”旧”,”新”)」は、文字列の中の該当部分を変えます。完全一致の「区分=”旧A”」と意味が異なり、「旧式部品」など別の値にも影響する可能性があるため、選択クエリの計算列で変更後を確認してから使います。
変換パターンが増える場合は、旧値と新値を並べた変換マスターを用意します。旧値が重複し、一つの値から複数の新値へ対応する状態は解消してください。対応がない行を「変換漏れ一覧」に出し、勝手に空文字へ置き換えない運用にすると、データ品質を保ちやすくなります
更新できない場合と誤更新時の対処
更新できないときは、書き込み可能なテーブルか、結合や集計によって読み取り専用になっていないか、入力規則や参照整合性に違反していないかを確認します。エラーを消すために制約を外すと、不正な値が保存されるため、まず拒否された理由を調べてください。
| 症状 | 確認する場所 | 対応 |
|---|---|---|
| 0件更新になる | WHERE条件・処理済・バッチ | 条件と実データを照合 |
| 型が一致しない | 更新値とフィールド型 | 数値・日付・文字列を分ける |
| 更新可能なクエリが必要と出る | 集計・結合・リンク元 | 更新先のテーブルを明確にする |
| 入力規則違反になる | 必須・範囲・参照関係 | 不正値を修正して再確認 |
| 一部が更新されない | ロック・権限・競合 | 作業停止と対象の再照合 |
誤更新に気付いたら、まず追加の更新や取込を止めます。次に、現在の状態を別途保全し、実行したクエリ、対象バッチ、時刻、件数を記録します。慌てて逆方向の置換を実行すると、もともと正しかった同じ値まで変えてしまう可能性があります。
バックアップと更新前のID・値を比較し、復元する範囲を決めます。全体復元でよいか、更新対象だけを戻すべきかは、バックアップ以降の正しい変更があるかで異なります。リンク先がSQL Serverなどの場合は、そのデータ基盤の管理者と復旧手順を合わせてください。
定型処理を業務として管理する
毎日の処理をボタン一つにする前に、取込、検査、確認、更新、照合の順序を固定します。ボタンの簡単さより、「今日はどのデータを何件処理したか」が追えることを優先します。作業担当が替わっても、未処理と処理済を区別できる状態が必要です。
実行記録には、取込バッチ、処理名、実行日時、担当者、想定件数、実更新件数、成否を残します。業務上必要なら、対象IDと変更前後の値も保管します。ただし個人情報を含む記録は保管先や閲覧範囲を決め、不要なコピーを増やさない運用にします。
本番へ反映する前は、正常値、対象外、未入力、既に変換済み、二重実行、ロックや保存失敗を確認します。処理を変更するときも、同じテスト用データで以前と結果を比較します。処理済フラグの意味が複数の処理で変わる場合は、処理別の履歴テーブルへ整理することを検討しましょう。
よくある質問
通常の元に戻す操作では取り消せません。実行前にバックアップを取り、同じ条件の選択クエリで対象を確認することが基本です。更新前の対象IDと値を残しておくと、誤更新時に影響を調べやすくなります。ただしバックアップ以降に別の正しい入力がある場合、全体を戻すとその入力まで失われます。誤りに気付いたら追加処理を止め、現在の状態を保全してから復元範囲を判断してください。逆方向の置換だけで戻そうとする方法は避けましょう。
すべてを移す必要はありません。一度だけの変更ならExcelの置換で十分な場合があり、毎日のCSV整形ならPower Queryで変換手順を保存する方法もあります。Accessでも表示用の名称をそろえるだけなら、選択クエリや変換マスターで元データを残せます。更新クエリが必要なのは、保存値自体を条件付きで訂正したい場合です。元データの保存、繰り返し処理、複数人の利用、復元の要件を整理し、最も管理しやすい方法を選んでください。
更新内容によります。旧Aを標準Aへ変える処理で、旧Aだけを条件にしていれば、二回目は対象がなくなる設計にできます。一方、金額を1.1倍する処理や文字を付け足す処理は、再実行するとさらに値が変わります。元の値から再計算する、取込バッチと未処理条件を組み合わせる、実行履歴を確認するなどの対策が必要です。また、同じCSVを別レコードとして二重取込した場合は処理済フラグだけでは防げないため、取込時の重複検査も行います。
画面に見えている行だけが更新されるとは限りません。更新対象を決めるのは、更新クエリ自身に書かれたWHERE条件です。フォームのフィルターが、別の更新クエリへ自動で引き継がれると考えないでください。対象バッチ、更新前の値、処理済の状態などをクエリ内で明示し、同じ条件の選択クエリでIDと件数を確認します。ボタンへ組み込む場合も、どの条件をパラメーターで渡すかを決め、画面の対象件数と実際の更新件数を照合してください。
完全一致の条件は、例えば区分が旧Aである行だけを選び、項目全体を標準Aへ変えます。Replace関数は文字列の一部分を置き換えるため、想定外の単語の中にも同じ文字があれば変更される可能性があります。名称や備考の一部を直す場合は、対象列を限定し、選択クエリで変更前と変更後を並べて確認してください。変換候補が多い業務では、旧値と新値の対応表を管理する方法もあります。未対応の値や重複した対応を先に見つけることが大切です。
データがそのファイル内に保存され、他の利用者が使っていない状態など、整合したコピーを取れる条件なら一つの方法になります。ただしリンクテーブルを使っている場合、フロントエンドをコピーしただけでは実データの保護になりません。別ACCDBやSQL Serverなど、データを実際に保存する側のバックアップが必要です。復元時に他の人の正しい変更を失わないよう、作業時間と更新停止の範囲も決めます。コピーを作るだけでなく、戻せる手順を確認しておきましょう。
まとめ
更新クエリは毎日の置換を定型化できますが、安全性は実行前後の手順で決まります。保存値を変える必要があるかを先に判断し、選択クエリで対象IDと変更後を確認します。バックアップ、二重実行対策、結果照合、復旧手順まで用意してから、日常業務のボタンへ組み込んでください。
Accessの教科書で置換業務の改善を相談する
候補や集計条件が部署ごとに異なる、既存の画面を直せる担当者がいないなど、置換の手順だけでは解決しない場合は、現在のExcelと業務の流れを整理して相談すると検討が進みます。Accessの教科書のお問い合わせで、対象データ、利用人数、困っている操作をお知らせください。
関連記事
参考情報
［参考1］Microsoft UPDATE statement
https://learn.microsoft.com/en-us/office/client-developer/access/desktop-database-reference/update-statement-microsoft-access-sql
［参考2］Microsoft クエリの概要
https://support.microsoft.com/ja-jp/access/introduction-to-queries
［参考3］Microsoft 値の置換 Power Query
https://support.microsoft.com/ja-jp/excel/replace-values-power-query