2025.03.15 2025.03.15

Accessプロジェクト(.adp)の歴史と現状：SQL Server連携の移り変わり

nanikatoaccess

以下では、「Accessプロジェクト(.adp)の歴史と現状：SQL Server連携の移り変わり」をテーマに、かつて存在したAccessプロジェクト(.adp)ファイルの誕生と廃止の経緯、そして現代的なSQL Server連携の方法までを整理します。Microsoft AccessがどのようにSQL Serverとの連携を提供してきたか、その背景を知ることで、現在のベストプラクティスを理解しやすくなるでしょう。

1. Accessプロジェクト(.adp)とは？

.adp (Access Data Project) とは、Access 2000 で初めて導入されたSQL Server専用のフロントエンド形式のファイル形式です。従来の .mdb/.accdb ではJet/ACEエンジンを介してデータを管理しますが、.adpでは直接SQL Serverとやり取りをし、次のような特徴がありました。

特徴

Accessのテーブルオブジェクトが存在せず、SQL Serverデータベースに直接接続。

クエリの代わりにストアドプロシージャやビューをAccess上から簡単に管理。

フォームやレポートはAccessプロジェクト内に保持しつつ、実際のデータ定義はSQL Server側。

当時、Accessを使ってSQL Serverを本格的に操作したいユーザーにとっては、.adpが非常に便利な選択肢でした。

2. .adpの歴史：導入から廃止まで

ないものはない！お買い物なら楽天市場

2.1 Access 2000での登場

1999年頃（Access 2000のリリース）
.adp形式が導入され、AccessアプリをSQL Serverバックエンド専用に特化させる形を提供
当時はJetエンジンの容量制限や同時アクセス性能などの課題があり、SQL Server連携を強化する手段として注目を集める

2.2 Access 2002/2003での改良

ストアドプロシージャやビューの管理機能向上
ただしリレーショングラフや一部のクエリデザイン機能はアクセスプロジェクトで制限がある
SQL Server 2000との組み合わせがメイン運用だった

2.3 Access 2007/2010時代：将来の不安

MicrosoftがOffice製品全体でUIを刷新する中、.adpへの機能強化が停滞
Access 2007/2010も一応.adpを扱えるが、「.accdb」に注力している様子が伺える
SQL Serverとの連携は、リンクテーブル方式やADOの活用が優勢になり始める

2.4 Access 2013以降：.adpの廃止

Access 2013 で**.adpファイルの作成とデザインサポートが事実上廃止**。
公式ドキュメントでも**「.adpは推奨されない」**とアナウンスされ、既存の.adpを使い続ける場合はAccess 2010以前を継続使用するしかなくなった
以降は、.accdb + ODBCリンクテーブル や パススルークエリ、ADO/DAOなどの方法が標準

3. なぜ廃止されたのか？

いくつかの理由が考えられます：

機能的重複とメンテナンスコスト
- Accessが本来持つJet/ACEエンジンによるローカルDB運用と、.adpのSQL Server直結という二重の仕組みを保守するのが負担
- Windows/Officeの進化やSQL Serverの更新に合わせる調整が複雑
リンクテーブル方式の汎用性
- .adpはSQL Serverに特化していたが、他のDBと連携したいニーズも拡大
- .accdbファイルでDSNレス接続やADOを使えば、OracleやMySQLなど多彩なDBを扱えるため、こちらが標準的なアプローチになった
クラウド時代へのシフト
- Office 365やAzureなどクラウドサービスの台頭で、.adpの特化型モデルが合わなくなった
- Azure SQL Databaseをリンクテーブルやパススルークエリで扱うのが主流へ移行

4. 現在の推奨されるSQL Server連携方法

.adpが廃止された今、AccessとSQL Serverを連携する場合は以下の方法が主流です。

.accdbファイル + リンクテーブル
- 「外部データ → ODBCデータベース」でリンクテーブルを作成し、SQL Server上のテーブルやビューをAccess内で扱う
- Accessのフォームやレポートは従来通り使え、実際のデータ保存はすべてSQL Server側に
パススルークエリ
- 複雑なJOINや集計をAccessエンジンで処理せず、SQL Serverに直接渡す形で高速化
- Accessクエリで「SQLのパススルー」を選択し、ODBC接続文字列を設定。実際に書くSQL文はサーバー方言のままになる
VBA(AOD/DAO)でADO接続
- フォームイベントなどでADOを使い、SQL Serverに直接クエリを発行
- 動的にSQL文を組み立てたり、ストアドプロシージャを呼び出して結果をレコードセットで受け取る
SQL Serverのビュー/ストアドプロシージャとの組み合わせ
- Access側は軽量なフロントエンドとし、重い処理はサーバー側で行う
- ストアドプロシージャをパススルークエリやADOコマンドで呼び出す形が安定

5. 既存の.adpをどう移行すべきか？

もし古い環境で.adpファイルを使っている場合、Microsoftは**.accdbへ移行**することを推奨しています。

テーブル/ビュー/ストアドプロシージャはSQL Server上に残す
- 既にSQL Serverにデータがあるなら、テーブル類はそのまま
Accessのオブジェクト（フォーム、レポート、マクロ、VBAコード）を.accdbファイルに移行
- 新規に.accdbを作成し、フォーム等をインポートまたは再作成
リンクテーブル/パススルークエリを設定
- 旧.adpで編集していたテーブルやストプロを、ODBC接続で参照できるようにする
VBAコード修正
- ADP固有のプロパティや機能を使っていた部分を、DAOやADOに置き換える
テストと最適化
- フォームやレポートの動作確認を行い、パフォーマンスが落ちるところはパススルークエリやストアドプロシージャ呼び出しで改善

6. .adp廃止を踏まえた今後のベストプラクティス

Accessをフロントエンドとして活かす一方、バックエンドDBはSQL Server(オンプレ/クラウド)に任せる構成が基本
.accdbでリンクテーブル+パススルークエリ+VBA(ADO/DAO) という汎用的な形が最終的に推奨される
将来的にAzureや他DBへ移行したい場合も、.accdbのままODBC接続を切り替えるだけで済むため、拡張性が高い

7. まとめ：.adpの歴史と現代の連携手法

.adpの登場: Access 2000でSQL Serverを直接扱うファイル形式として導入
隆盛と停滞: 一時期はSQL Server連携の推奨手段だったが、Officeの進化とリンクテーブルの汎用性向上により役割が相対的に縮小
Access 2013で廃止: .adpは開発サポートを外され、今では推奨されない方法
現在の主流: .accdb + ODBC（リンクテーブル/パススルークエリ/ADO） でSQL Serverと連携するのがベスト
移行手段: 既存.adpユーザーは早めに.accdbへコンバートし、ODBC接続へ変更するのが望ましい

AccessとSQL Serverを組み合わせる際、.adpの使用はもはや選択肢外ですが、後継となるリンクテーブル方式やパススルークエリが十分成熟しており、さらにパフォーマンスや拡張性も向上しています。歴史的経緯として学んでおくのは大切ですが、実運用では最新の.accdb+ODBC構成を是非活用してみてください。

関連記事

リンクテーブル管理と再接続のベストプラクティス

パススルークエリの高度利用

Access×SQL Server 連携の手順とベストプラクティス

.adp はかつてSQL Server連携の希望として注目されましたが、Officeのバージョンアップとクラウド化の波に伴い廃止へと向かったのが実情です。今後はぜひ、.accdb + ODBCというスタイルでスケーラブルかつ保守性の高いシステムを実現してください。

DMM

ABOUT ME