2 アップサイジングウィザードの実行

Access+SQL Serverで構成されたクライアント/サーバーシステムを構築するには、一からシステム開発を行うこともできます。Accessでいうところの「空のデータベース」からクライアント側の開発を行い、SQL Serve側も適宜順番にテーブルやビュー・ストアドプロシージャ・ストアドファンクションといったオブジェクトを作っていく方法です。特にADPとして開発すれば、SQL Serverデータベースに直接的(いわゆる“ネイティブ”に)にアクセスできますので、Access上のインタフェースを使ってSQL Server上のオブジェクトを新規作成したり編集したりすることができます。つまり、Access単体のデータベースと同じように、ひとつのAccessファイル上でSQL Server側の開発もAccess側のフォームやレポート、モジュールも開発できるわけです。

一方、今回の場合は、既存のAccessのデータベースをSQL Server対応に“アップサイジング”するということで、すでにAccessのスタンドアロンのデータベースファイル(.accdb形式)が作られているということを前提としています。そのような場合、Accessには非常に便利なツールが用意されています。『アップサイジングウィザード』というツールです。

これを使えば、対話式でいろいろな設定していくことで必要なオブジェクトをAccessからSQL Server側に転送したり、ファイル形式をADPに変換したりすることができます。これを使わない手はありませんので、今回はこのツールを使った方法でのアップサイジング作業手順を説明していきたいと思います。


アップサイジングウィザードを使ったアップサイジング手順は次の通りです。なお、SQL Serverは事前に起動しているものとします。

  1. まず、既存のAccessデータベースファイルを開きます。Shiftキーを押すなどして起動時の設定はパスしておいた方がよいかもしれません。


  2. 次に、リボンの[データベースツール]タブより[データの移動]-[SQL Server]のボタンをクリックします。

    これによって「アップサイジングウィザード」が起動します。

  3. アップサイジングウィザードの最初の画面では、すでにSQL Server上に作成済みのデータベースを使うか、それともこのAccessデータベース用に新しいデータベースを作成するかを選択します。
    ここでは、「新しいデータベースを作成する」を選択して[次へ]ボタンをクリックします。


  4. 次の画面では、ネットワーク上で稼働しているSQL Serverが検索されますので、コンボボックスのリストの中から、今回使用するSQL Serverを選択します。
    またそのSQL Serverに対する接続方法を選択します。Windows認証(セキュリティ接続)またはSQL Server認証から選択、さらにSQL Server認証を使う場合にはログインIDやパスワードを入力します。
    また、新規に作るデータベース名を指定します。
    ここでは、下図のような設定とし、[次へ]ボタンをクリックします。


  5. 次に、Access側からSQL Serverへと移行するテーブルを選択します。
    ここではすべてのテーブルを対象とすることとし、[>>]ボタンをクリックして全テーブル名を画面右に移したあと、[次へ]ボタンをクリックします。


  6. 次の画面では、テーブルのどの属性をSQL Server上へも反映させるかを指定することができます。
    ここでは、すべてデフォルト設定のままとし、そのまま[次へ]ボタンをクリックします。


  7. 次の画面では、ウィザードによってテーブルの移行処理が完了したあとに、このAccessのデータベースとSQL Serverのデータベースをどのような関係にするかを選択します。

    「変更なし」
    テーブルをSQL Server上に移行しますが、このAccess自体には変更を加えません。結果的にSQL Server上にテーブルやその属性が生成されるだけとなります。

    「SQL Serverのテーブルを既存のアプリケーションにリンクさせる」
    テーブルをSQL Server上に移行したあと、そのテーブルをODBC経由のリンクテーブルとしてこのAccess上に設定します。これによってこのAccessデータベースからは従来のローカルテーブルに代わってSQL Server上のテーブルのデータを扱えるようになります。

    「新しいAccessクライアント/サーバーアプリケーションを作成する」
    AccessのデータファイルをAccessプロジェクト(.ADPファイル)化して、直接的にSQL Serverデータベースを扱えるようにします。

    ここでは、3番目の「新しいAccessクライアント/サーバーアプリケーションを作成する」を選択します。これを選択すると「ADPファイル名」の入力欄が有効になりますので、ADPファイルを指定します(このことからこのAccessデータベースファイルとは別にADPファイルが生成されることが予想できると思います)。


  8. [次へ]ボタンをクリックすると、最終確認の画面になりますので、ここではそのまま[完了]ボタンをクリックします。
    それによってアップサイジングの処理が実行されます。


  9. 処理中は下図のような画面が表示されますので、すべての処理が完了するのを待ちます。


  10. すべての処理が完了すると、「アップサイジングウィザードレポート」というレポートが表示されます。必要であれば印刷しておきます。


  11. このレポートのプレビューを閉じると、今回のウィザードの設定の場合には、これまでのAccessデータベースが閉じられ、自動的にAccessプロジェクトのファイルが起動します。


以上で、とりあえずアップサイジングウィザードによる基本的なアップサイジングの作業は完了です。

  • 今回の場合、Accessデータベース(.accdb)ではDAOを使っており、またADPファイルが開かれた時点で自動的にVBAの処理が実行されるような起動時の設定になっているため、プログラムエラーが発生します。これはADPではDAOは使えないためです。これについてはあとで説明・修正していくものとします。


ここで、SQL ServerならびにADPファイル内のオブジェクトを確認してみます。
  • SQL Server上には指定された名前のデータベース「JinzaiDB」が生成されていることが分かります。
  • テーブルについてはそのままSQL Server上に生成され、Access上にもそれが表示されています。
  • 選択クエリについては、SQL Server上では「ビュー」と「テーブル値関数」というふたつに種類に分割されています。Access上ではナビゲーションウィンドウのクエリのアイコンでその違いを確認することができます。
  • 上図では分かりませんが、アクションクエリはどちらからも抹消されています。
  • フォームやレポート・モジュールについては、accdbでもADPでも基本的には同じ(厳密にはプロパティ等いろいろ違いがあります)ですので、そのままの形で残っています。

アップサイジングウィザードによって確かにテーブル構造やデータはSQL Serverに移行しており、データ管理もしくはデータベースとしてはアップサイズしているのですが、DAOのプログラムによるエラー、アクションクエリが消えているなど、いくつか問題がありデータベース“アプリケーション”としてはこのままではアップサイジングが完了したとは言えません。そこで次回以降、これらの修正を行っていきます。
| Index | Prev | Next |

 

Copyright © T'sWare All rights reserved