Access データベースを SQL Server に移行する

データベースの分割について

すべての Access データベース オブジェクトは、1 つのデータベース ファイルに格納することも、フロントエンド データベースとバックエンド データベースという 2 つのデータベース ファイルに格納することもできます。 これは データベースの分割 と呼ばれ、ネットワーク環境での共有を容易にするように設計されています。 バックエンド データベース ファイルには、テーブルとリレーションシップのみを含む必要があります。 フロントエンド ファイルには、フォーム、レポート、クエリ、マクロ、VBA モジュール、バックエンド データベースへのリンク テーブルなど、他のすべてのオブジェクトのみを含める必要があります。 Access データベースを移行すると、SQL Serverがサーバー上にあるデータの新しいバックエンドとして機能している分割データベースに似ています。

その結果、SQL Server テーブルにリンクされたテーブルを含むフロントエンド Access データベースを引き続き維持できます。 効果的に、Access データベースが提供する迅速なアプリケーション開発の利点と、SQL Serverのスケーラビリティを引き出すことができます。

SQL Serverの利点

まだSQL Serverに移行するためにいくつかの説得力が必要ですか? 考慮する必要があるその他の利点を次に示します。

• 同時実行ユーザーの数が増える    SQL Serverは、Access よりも多くの同時実行ユーザーを処理でき、追加されたユーザー数が多い場合にメモリ要件を最小限に抑えることができます。

• 可用性の向上    SQL Serverを使用すると、データベースの使用中にデータベースを増分または完全に動的にバックアップできます。 その結果、データをバックアップするために、ユーザーにデータベースへのアクセスを強制的に終了してもらう必要はありません。

• 高パフォーマンスとスケーラビリティ    通常、SQL Server データベースは Access データベースよりも優れたパフォーマンスを発揮します。特にテラバイトサイズの大規模なデータベースではパフォーマンスが向上します。 また、SQL Serverは、1 つのプロセス内で複数のネイティブ スレッドを使用してユーザー要求を処理することで、クエリを並列処理することで、クエリをはるかに高速かつ効率的に処理します。

• セキュリティの強化    信頼された接続を使用して、SQL Serverは Windows システム セキュリティと統合され、ネットワークとデータベースへの 1 つの統合アクセスを提供し、両方のセキュリティ システムを最大限に活用します。 これにより、複雑なセキュリティ スキームの管理がはるかに簡単になります。 SQL Serverは、社会保障番号、クレジット カード データ、機密アドレスなどの機密情報に最適なストレージです。

• 即時復旧可能性     オペレーティング システムがクラッシュした場合、または電源が切れた場合、SQL Serverは、データベース管理者の介入なしで、数分で一貫性のある状態にデータベースを自動的に回復できます。

• VPN の使用    アクセスと仮想プライベート ネットワーク (VPN) が機能しません。 ただし、SQL Serverでは、リモート ユーザーは引き続きデスクトップ上の Access フロントエンド データベースと、VPN ファイアウォールの背後にある SQL Server バックエンドを使用できます。

• Azure SQL Server    SQL Serverの利点に加えて、ダウンタイムのない動的なスケーラビリティ、インテリジェントな最適化、グローバルなスケーラビリティと可用性、ハードウェア コストの排除、管理の削減を実現します。

最適な [Azure SQL サーバー] オプションを選択する

Azure SQL Server に移行する場合は、それぞれ異なる利点を持つ 3 つのオプションから選択できます。

• 単一データベース/エラスティック プール    このオプションには、SQL Database サーバーを介して管理される独自のリソース セットがあります。 1 つのデータベースは、SQL Serverの包含データベースに似ています。 エラスティック プールを追加することもできます。これは、SQL Database サーバーを介して管理されるリソースの共有セットを持つデータベースのコレクションです。 最も一般的に使用されるSQL Server機能は、組み込みのバックアップ、パッチ適用、および回復で使用できます。 しかし、正確なメンテナンス時間は保証されておらず、SQL Serverからの移行は難しい可能性があります。

• マネージド インスタンス    このオプションは、リソースの共有セットを持つシステム データベースとユーザー データベースのコレクションです。 マネージド インスタンスは、オンプレミスとの互換性が高いSQL Server データベースのインスタンスSQL Server似ています。 マネージド インスタンスには、バックアップ、修正プログラムの適用、回復が組み込まれており、SQL Serverから簡単に移行できます。 ただし、使用できないSQL Server機能が少なく、正確なメンテナンス時間は保証されません。

• Azure Virtual Machine    このオプションを使用すると、Azure クラウド内の仮想マシン内でSQL Serverを実行できます。 SQL Server エンジンと簡単な移行パスを完全に制御できます。 ただし、バックアップ、パッチ、回復を管理する必要があります。

詳細については、「Azure へのデータベース移行パスの選択」と「Azure SQLとは」を参照してください。

最初の手順

SSMA を実行する前に移行プロセスを合理化するのに役立つ、事前に対処できるいくつかの問題があります。

• テーブル インデックスと主キーを追加する    各 Access テーブルにインデックスと主キーがあることを確認します。 SQL Serverでは、すべてのテーブルに少なくとも 1 つのインデックスが必要であり、テーブルを更新できる場合は、リンク テーブルに主キーが必要です。

• 主キーと外部キーのリレーションシップを確認する    これらのリレーションシップが、一貫性のあるデータ型とサイズを持つフィールドに基づいていることを確認します。 SQL Serverでは、外部キー制約で異なるデータ型とサイズを持つ結合列はサポートされていません。

• [添付ファイル] 列を削除する    SSMA では、Attachment 列を含むテーブルは移行されません。

SSMA を実行する前に、次の最初の手順を実行します。

1. Access データベースを閉じます。

2. データベースに接続されている現在のユーザーもデータベースを閉じていることを確認します。

3. データベースが ファイル形式.mdb場合は、 ユーザー レベルのセキュリティを削除します。

4. データベースをバックアップします。 詳細については、「 バックアップと復元プロセスを使用してデータを保護する」を参照してください。

ヒント    最大 10 GB をサポートし、移行を実行してチェックする無料で簡単な方法である、Microsoft SQL Server Expressエディションをデスクトップにインストールすることを検討してください。 接続するときは、 LocalDB をデータベース インスタンスとして使用します。

ヒント    可能であれば、スタンドアロン バージョンの Access を使用します。 Microsoft 365のみを使用できる場合は、Access 2010 データベース エンジンを使用して、SSMA を使用するときに Access データベースを移行します。 詳細については、「 Microsoft Access Database Engine 2010 再頒布可能パッケージ」を参照してください。

クエリ

選択したクエリのみが変換されます。パラメーターを受け取るクエリの選択など、他のクエリは含まれません。 一部のクエリは完全に変換されない場合があり、SSMA は変換プロセス中にクエリ エラーを報告します。 T-SQL 構文を使用して、変換しないオブジェクトを手動で編集できます。 構文エラーでは、Access 固有の関数とデータ型をSQL Serverに手動で変換する必要がある場合もあります。 詳細については、「Access SQL と SQL Server TSQL の比較」を参照してください。

データ型

アクセスとSQL Serverには同様のデータ型がありますが、次の潜在的な問題に注意してください。

大きい数値    Large Number データ型は、非通貨の数値を格納し、SQL bigint データ型と互換性があります。 このデータ型を使用すると、大量の数値を効率的に計算できますが、Access 16 (16.0.7812 以降) .accdb データベース ファイル形式を使用する必要があり、64 ビット バージョンの Access でパフォーマンスが向上します。 詳細については、「 Large Number データ型の使用 」および「 64 ビットバージョンまたは 32 ビット バージョンの Office を選択する」を参照してください。

はい/いいえ    既定では、Access Yes/No 列は SQL Server ビット フィールドに変換されます。 レコードのロックを回避するには、ビット フィールドが NULL 値を許可しないように設定されていることを確認します。 SSMA では、ビット列を選択して、 Allow Nulls プロパティを NO に設定できます。 TSQL では、 CREATE TABLE ステートメントまたは ALTER TABLE ステートメントを 使用します。

日付と時刻    日付と時刻に関するいくつかの考慮事項があります。

• データベースの互換性レベルが 130 (SQL Server 2016) 以上で、リンク テーブルに 1 つ以上の datetime 列または datetime2 列が含まれている場合、テーブルは結果に #deleted メッセージを返す可能性があります。 詳細については、「データベースが #deleted を返 SQL-Server リンク テーブルにアクセスする」を参照してください。

• Datetime データ型にマップするには、Access 日付/時刻データ型を使用します。 Access Date/Time Extended データ型を使用して、日付と時刻の範囲が大きい datetime2 データ型にマップします。 詳細については、「日付/時刻拡張データ型の使用」を参照してください。

• SQL Serverの日付を照会する場合は、時刻と日付を考慮してください。 次に例を示します。

  • DateOrdered 1/1/19 から 1/31/19 の間には、すべての注文が含まれていない場合があります。

  • DateOrdered between 1/1/19 00:00:00 AM and 1/31/19 11:59:59 PM には、すべての注文が含まれます。

添付   Attachment データ型は、Access データベースにファイルを格納します。 SQL Serverでは、考慮すべきいくつかのオプションがあります。 Access データベースからファイルを抽出し、SQL Server データベースにファイルへのリンクを格納することを検討できます。 または、FILESTREAM、FileTables、またはリモート BLOB ストア (RBS) を使用して、添付ファイルを SQL Server データベースに格納したままにすることもできます。

ハイパーリンク    アクセス テーブルには、SQL Serverがサポートしていないハイパーリンク列があります。 既定では、これらの列はSQL Serverの nvarchar(max) 列に変換されますが、より小さいデータ型を選択するようにマッピングをカスタマイズできます。 Access ソリューションでは、コントロールの Hyperlink プロパティを true に設定した場合でも、フォームとレポートで ハイパーリンク の動作を使用できます。

複数値フィールド    Access 複数値フィールドは、区切られた値のセットを含む ntext フィールドとしてSQL Serverに変換されます。 SQL Server では多対多リレーションシップを表す複数値を持つデータ型はサポートされていないため、追加のデザインや変換作業が必要になる可能性があります。

Access と SQL Server データ型のマッピングの詳細については、「データ型の比較」を参照してください。

メモ    複数値フィールドは変換されません。

詳細については、「 日付と時刻の型」、「 文字列型とバイナリ型」、「 数値型」を参照してください。

Visual Basic

VBA はSQL Serverではサポートされていませんが、次の問題が発生する可能性があることに注意してください。

クエリの VBA 関数    アクセス クエリでは、クエリ列のデータに対する VBA 関数がサポートされます。 ただし、VBA 関数を使用する Access クエリはSQL Serverで実行できないため、要求されたすべてのデータが処理のために Microsoft Access に渡されます。 ほとんどの場合、これらのクエリは パススルー クエリに変換する必要があります。

クエリのユーザー定義関数    Microsoft Access クエリでは、VBA モジュールで定義されている関数を使用して、渡されたデータを処理できます。 クエリには、スタンドアロン クエリ、フォーム/レポート レコード ソースの SQL ステートメント、フォーム、レポートとテーブル フィールドのコンボ ボックスとリスト ボックスのデータ ソース、既定または検証ルール式を指定できます。 SQL Serverは、これらのユーザー定義関数を実行できません。 これらの関数を手動で再設計し、SQL Serverのストアド プロシージャに変換する必要がある場合があります。