事例：マイクロソフトのNorthwindデータベースを、Access 97からSQLとブラウザへ

出発点

• 2,932 KBのAccess 97ファイル1つ。テーブル9個（計4,032行）、保存済みクエリ22個（パラメータークエリ3個、クロス集計クエリ1個を含む）、レポート13個、フォーム21個。
• OLEオブジェクトとして保存された画像。Accessでしか表示できません。
• フィールドのプロパティ、リレーションシップ、レポートの元になるクエリに分散した業務ルール。

行ったこと

1. データ。すべてのテーブルとすべての行を新しいリレーショナルスキーマに移し、SQLiteデータベースとPostgreSQLスクリプトの両方で納品しました。主キー、外部キー、インデックスを備え、Accessの入力規則はデータベースの制約に変換しています。17枚の画像はピクセル単位でそのままPNGファイルにしました。
2. クエリ。保存済みクエリ22個を、両方のデータベースで同じ名前のSQLビューにしました。レポートで使う計算、つまり値引き後の受注合計、請求金額、カテゴリー別・年別の売上も含みます。
3. 検証。自動テストで元のファイルと新しいデータベースを比較しました。テーブルごとの行数と全行のチェックサム、そして全クエリの結果全体を、計855回の実行で、4通りの方法（元ファイル上のAccess SQL、独立したモデル、PostgreSQL、ブラウザ）で確認しています。
4. アプリ。移行後のデータベースを使い、すべてブラウザ内で動くウェブアプリ。合計がその場で計算される受注、顧客、商品、仕入先、社員、ダッシュボード、印刷できる元のレポートを備えています。

実行結果

9/9

テーブルが1行単位で一致

22/22

クエリの結果が一致（855回実行）

17/17

ルール違反の試みをデータベースが拒否

$1,265,793.02

受注明細2,155行の金額。SQLite、PostgreSQL、ブラウザで同じ値

二つの違い、どちらも意図したもの

Accessは受注明細を2進浮動小数点で計算し、値引き率を近似値で保存しています（15%は0.15000000596として保存）。2,155行のうち、正確な金額がちょうど0.5セントになる18行では、そのために結果が1セントずれます。新しいデータベースは正確なパーセンテージを保存し、どこでも同じ方法で端数を処理するため、総合計は$0.16変わります。影響を受ける行はすべてレポートに記載しています。

148個のテキスト値から、末尾の余分な空白や古い形式の改行を取り除きました。その一つが国名のSwedenで、1件だけ末尾に空白付きで保存されており、そのままでは別の国として数えられるところでした。

テストの途中でわかったこと

JavaからAccessファイルを読むためによく使われるツールUCanAccessは、このAccess 97ファイルの値引き率の列を整数として読み込み、838件の値引きがすべてゼロになってしまいます。テーブルの照合でこれを発見し、同じ条件で比較した方法をレポートで説明しています。また、Jackcessが再構成するSQL文ではあるクエリのTOP 10が抜け落ちるため、ファイルのシステムテーブルから読み取りました。