MS ACCESSからPostgreSQLへ移行する


2005.12 ACCESS 2000 SP-3 + PostgreSQL 8.0.4

なぜ移行するのか

ACCESSからPostgreSQLやMySQLに移行したい理由は多様に存在するでしょう。

  1. MDBファイルが壊れやすい。
  2. ファイル共有型のACCESSではLANの負荷が高い。
  3. MDBファイルで扱うにはデータ件数が増えすぎた。
  4. WEBでもデータを利用したい。が、Windows Server+IISだとサーバーライセンスに金がかかるので、ライセンス料のかからないLinux+Apache+PHP+PostgreSQLあたりの構成にしたい。
  5. ACCESSのバージョンアップに付き合いきれなくなった。または複数バージョンの共存が破綻した。もうACCESS嫌だ。

などなど。

1.や2.が理由なら、そして、現在のACCESSアプリケーションが、データ用MDBファイルとアプリケーション用MDBファイルを分けていなかったり、データ用MDBファイルを分離していても、その分離したMDBのテーブルを更新可能なフォームのデータソースに指定していたりするものなら、1.や2.の問題を解決するために、ACCESSでできることがまだまだありますので、苦労の多いシステム移行を考えるより、もう少しACCESSの能力を引き出す努力をする方がよいでしょう。

5.が理由なら、以下で書いてあることはまったく価値のないことなので、早々にこの文章を読むことを打ち切り、新しいクライアントアプリケーションの製作に参考になるところへ移るのがよいでしょう。

 

何を移行するのか

システムを移行するにしても、移行程度は複数存在します。

  1. 新規にアプリケーションを作り直し、ACCESSを捨ててしまう。
  2. データベース機能だけを移行して、ユーザーインターフェースにはACCESSアプリケーションを改造して使う。

金と時間があるなら移行方法1.でデータベース定義まで見直すのがいいでしょう。しかし、ACCESSは強力なデータ連結フォームと柔軟なレポートを持っているので、ACCESS+VBAで作りこんだアプリケーションを移行するのは相当に骨の折れる作業です。

帳票フォームだとか、フリガナ入力支援、郵便番号・住所入力支援、定型入力、複数列リストボックス・コンボボックス、Enterキーで次のコントロールに移動したり、フォーカス取得時に内容を選択状態にしたりといったことをプロパティ一つで制御できる、などACCESSではあたり前の機能を"標準"で揃えた開発ツールはなかなかありませんので。

そこで、アプリケーション開発ツールとしてのACCESSにしがみついたままデータベースだけをPostgreSQLに移行する方法を考えます。

 

どう移行するのか

現在のACCESSアプリケーションのつくりが、

ものなら、少ない手間でPostgreSQLに移行できるでしょう。

全体像は↓です。ADO.NETでメモリ上のDataTableやDataSetが果たしている役割を作業テーブルが果たします。

もともと処理に必要なデータだけをアプリケーションMDBに取得し、処理を終えたらデータMDBに反映するという形式で作成したアプリケーションは、データベース・ユーザーインターフェース一体型のACCESSアプリケーションでありながらデータベース機能が分離された状態ですので、アプリケーションMDBへのデータ取得とデータ反映部分をPostgreSQL用に書き換えるだけで動く可能性が高いです。

ACCESSに用意されてる落とし穴は、スタンドアロンでローカルHDDに置いたMDBの流儀で、ついつい、何千何万件もデータの入ったテーブルを入力フォームのデータソースにしてしまう点にあります。このような流儀で作ったACCESSアプリケーションはそのままでは、PostgreSQLのようなデータベースを利用したアプリケーションに移行できません。正確には移行してもあまり意味がありません。そのようなアプリケーションは、元のアプリケーションと同じくLANに負荷をかけ、データベースサーバーの負荷が高く、同時実行性の低いものになります。

 

どうやってPostgreSQLに繋ぐか

postgresqlとの通信プロトコルを覚えることなく、お手軽にPostgreSQLデータベースを操作するにはミドルウエアを使います。
ACCESSまたはそのVBAからPostgreSQLに接続するためのミドルウエアには、以下のものがあります。

各ミドルウエアを使ったサンプルコードはこちら

ACCESS自体の歴史が古く過去の遺物(DAO、ODBC Direct(RDO)もうすぐADOも)をたくさん背負っているので、PostgreSQLとのデータやりとり方法も多数存在します。

  1. DAO + リンクテーブル + ODBC Driver (+パススルークエリ
  2. DAO/ODBC Direct + ODBC Driver
  3. ADO + {OLE DB Provider for Microsoft Jet} + リンクテーブル + ODBC Driver
  4. ADO + {Microsoft OLE DB Provider for ODBC} + ODBC Driver
  5. ADO + OleDbプロバイダ

1.や3.でリンクテーブルだけを使う場合は、SQL文に注意しないとJETがSQL文を処理してしまうので、ネットワーク負荷はMDBファイル共有型と変わらず、PostgreSQLはリレーショナルデータベースとしての機能を発揮できない場合があります。この理由によりリンクテーブルを主とする1.の方法は除外して、移行の手間を少なくするという観点から、現在のアプリケーションがDAOで記述されているなら2.、ADOなら4.か5.というように選択すればよいと思います。

 

リンクテーブルではダメなのかに進む
ODBC Directとパススルークエリを使うに進む update 2006.2.2


TOPに戻る