概要
| この記事の結論 Access ADPの移行は、SQL Server上のデータと、ADP内の画面やVBAを分けて進めます。Access 2010がADP対応の最後のバージョンです。移行先にはACCDBとODBCリンクを使う構成や.NETなどがあり、拡張子の変更だけでは移行できません。既存接続と更新処理を調査してから代表画面で検証します。 |
この記事でわかること
- データと画面を分離
- 移行先を比較
- 接続処理を見直す
- 更新と帳票を検証
この記事の主な内容
- ADP移行で変わるものを把握する
- 移行先を3つの方針から選ぶ
- ADPとSQL Serverを調査する
- ACCDBとODBCで再構成する
- 移行後の更新と性能を検証する
- 本番切替と切り戻しを準備する
- よくある質問
想定読了時間：約8分
ADP移行で変わるものを把握する
ADPからの移行では、Access側のアプリケーションとSQL Server側の資産を別々に調べます。ADPはSQL Serverへ直接接続するAccessプロジェクトであり、データ本体をADPファイル内に保存する形式ではありません。ADPだけをコピーしても、業務全体のバックアップにはなりません。［Microsoft公式資料］
ADPの役割と対応世代
Microsoftの資料では、ADPを扱える最後のAccessは2010です。現行環境へ移すときは、対応しないファイルを開く工夫ではなく、接続方式とアプリケーションの移行を検討します。古いAccessを残すことは、移行作業のための一時的な手段として期間と用途を限定します。［Microsoft公式資料］
調査時には、ADPのフォーム、レポート、VBAに加え、SQL Serverのテーブル、ビュー、ストアドプロシージャ、権限を確認します。ストアドプロシージャとは、サーバーに保存して呼び出す処理です。画面から見えない場所に、採番や残高更新などの重要な業務ルールがある場合があります。
このため、最初に「ADPの画面を変える必要があるのか」「SQL Serverの更改も必要なのか」を分けます。二つを同時に変更すると、不具合が画面側かDB側かを切り分けにくくなります。
移行先を3つの方針から選ぶ
移行先は、Accessを継続する、.NETで再構築する、Webへ段階移行するという方針で整理できます。既存帳票と入力操作を残したいか、利用端末や外部連携を広げたいかによって、必要な変更範囲が変わります。
| 方針 | 主な構成 | 向いている条件 | 主な検討事項 |
|---|---|---|---|
| Access継続 | ACCDBとSQL Serverのリンク | 画面と帳票を活用したい | 接続と更新処理の変更 |
| .NET再構築 | WindowsアプリなどとDB | 保守体制や実装を刷新したい | 業務規則と帳票の再実装 |
| Webへ移行 | Webアプリと共通DB | 利用場所や端末を広げたい | 認証、API、ブラウザー操作 |
Access継続と全面再構築を比較する
Accessを続ける場合は、ACCDBをフロントエンドとし、SQL ServerのテーブルやビューへODBCで接続する方法が候補です。ODBCは、アプリケーションからデータベースへ接続するための仕組みです。Accessの画面を残せる可能性がある一方、ADP固有の動作まで同じとは限りません。［Microsoft公式資料］
また、データが既にSQL Serverにあるなら、移行の中心は必ずしもデータの再転送ではありません。SQL Server自体を更改する必要がなければ、まず画面側の接続と処理を再構成する計画を立てます。
ADPとSQL Serverを調査する
調査の目的は、ファイルを数えることではなく、どの画面がどのデータと処理に依存するかを把握することです。現行画面のスクリーンショット、帳票サンプル、日次・月次の処理手順を、利用部門から集めます。
画面とサーバーの依存関係を記録する
| 調査対象 | 記録する内容 | 見落とすと起きること |
|---|---|---|
| フォーム | 参照先、検索条件、保存のタイミング | 表示はできるが更新できない |
| VBA | 接続、コマンド、参照設定、外部部品 | ボタン操作でエラーになる |
| サーバー処理 | 引数、戻り値、更新対象、権限 | 計算や確定処理が変わる |
| 帳票 | データ抽出、集計、印刷条件 | 金額や改ページが変わる |
| 外部連携 | ファイル、メール、他システム | 日次業務の一部が止まる |
保全対象には、元ADP、関連ファイル、DBバックアップ、接続設定、権限設定を含めます。バックアップの存在だけでなく、検証環境へ復元できることも確認します。パスワードなどの秘密情報は、一般の仕様書とは分けて管理します。
SQL Serverのバージョン、照合順序、ドライバー、認証方式、利用者のAccessのbit数も記録します。サーバー管理者とアプリ保守担当が別の場合は、どこから先を誰が変更するかを決めておくと調査が進みます。
ACCDBとODBCで再構成する
ACCDBとODBCへ移す場合は、代表画面を一つ選び、接続から保存と帳票までを通して確認します。全オブジェクトの移植を先に進めると、共通する接続上の問題が後から多数の画面へ波及します。
RecordSourceと接続コードを見直す
フォームのRecordSourceは、画面に表示するデータの参照先です。ADPで使っていた参照先をACCDBに持ってくる際は、リンクテーブル、Accessクエリ、サーバー側の処理など、どの形で置き換えるかを決めます。
接続コードでは、CurrentProject.Connectionなど、現在開いているプロジェクトの接続に依存する処理を確認します。ACCDBで同じ記述を残した場合に、想定したSQL Server接続として使えるとは限りません。接続先を明示し、ADOやDAOの使い方を処理単位で見直します。
パススルークエリは、SQL Server側へSQLを送って実行する方法です。ただし、その結果を通常の編集可能なリンクテーブルと同じように扱う前提にはしません。参照画面と更新画面を分け、更新は専用処理にするなど、編集経路を決めます。
次に、引数の名前、型、Nullの扱い、日付、戻り値、更新件数を確かめます。ストアドプロシージャが成功したときの戻り値と、実際に更新された件数を混同すると、対象が0件でも画面上は完了になることがあります。
Access ADPから移行する方法の進め方に迷ったら
既存の画面や帳票をどこまで残せるか、接続や外部連携をどこから調べるべきか。依存関係が多い場合は、現状調査から進めると移行・改修の範囲を判断しやすくなります。お気軽に現在の構成と困っている業務をご相談ください。
移行後の更新と性能を検証する
接続テストが成功しても、業務移行は完了していません。追加、修正、削除、検索、帳票、月次確定を、業務担当者の操作で確認します。同じ入力を与えたときに、結果と更新内容が一致することを比較します。
主キーと同時更新を確認する
リンク先の行を一意に識別できるかを確認します。主キーのないテーブルや一意性が不明なビューは、表示できても期待どおりに更新できない場合があります。rowversionなどを用いた競合検知も候補ですが、列を追加するだけで、あらゆる競合がなくなるわけではありません。［Microsoft公式資料］
同時更新の検証では、二人が同じデータを開き、一人が保存した後で別の人が保存する状況を試します。後から保存した内容が無条件に上書きされないか、利用者が競合を理解して再操作できるかを確認します。
性能は、本番相当の件数とネットワーク条件で測定します。全件を取得してから端末側で絞り込む構成では、少量データの試験だけでは問題が現れないことがあります。対象期間やキーで必要な行に絞り、処理を行う場所を見直します。
本番切替と切り戻しを準備する
本番切替では、アプリの配布とDBの変更を別項目として管理します。アプリだけを戻せるのか、テーブルやストアドプロシージャにも変更があるのかによって、復旧方法が変わるためです。
DB変更とアプリ配布の順序を決める
1. 元のADPとDBを保全し、復元方法と接続先を記録します。
2. 代表画面を移行して、接続、更新、帳票の成立を確かめます。
3. 全対象の業務テストと利用者確認を行い、未解決の問題を判定します。
4. 必要な更新停止を行い、新しいアプリを配布して接続先を切り替えます。
5. 更新結果とエラーを監視し、問題があれば定義した条件で復旧します。
新アプリが更新したデータは、旧アプリへ戻しても自動的には元に戻りません。スキーマ変更の後方互換、追加・変更されたレコード、外部へ送信した内容を保全し、継続修正と切り戻しのどちらが適切かを判断します。
引継ぎには、原本の場所、配布版、接続設定、実行権限、定期処理、監視方法を残します。ADPが開かなくなったことだけを解消するのではなく、次回のOffice更新や担当者交代でも保守できる状態を目指します。
よくある質問（FAQ）
できません。ADPとACCDBは接続とオブジェクトの扱いが異なります。移行先を用意し、接続、画面、VBA、更新処理を再構成します。
必須ではありません。ADPのデータはSQL Server側にあります。サーバー更改が必要かと、Access側の移行が必要かを分けて判断します。
再利用できる部分はありますが、接続や参照先の修正が必要な場合があります。代表画面を使い、表示だけでなく保存、検索、帳票まで検証して範囲を決めます。
結果を通常の編集可能なリンクテーブルと同じように扱う前提にはしません。表示用の結果と、更新用の処理を分けて設計し、主キーや競合も確認します。
まず編集可能なADP原本と関連資料を探します。原本がなければ、SQL Server側のデータや処理、帳票、実際の操作から仕様を調査し、再構築範囲を判断します。
Access ADPから移行する方法の進め方に迷ったら
既存の画面や帳票をどこまで残せるか、接続や外部連携をどこから調べるべきか。依存関係が多い場合は、現状調査から進めると移行・改修の範囲を判断しやすくなります。お気軽に現在の構成と困っている業務をご相談ください。
参考情報
Microsoft：Create an Access project
Microsoft：Migrate an Access database to SQL Server
Microsoft：Ways to share an Access desktop database