スキップしてメイン コンテンツへ
Access データベースを SQL Server に移行する

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

すべての制限があり、Access データベースは例外ではありません。 たとえば、1つの Access データベースのサイズ制限は2gb で、同時ユーザー数が255を超えることはできません。 このため、Access データベースを次のレベルに移動するときは、SQL Server に移行することができます。 SQL Server (オンプレミスまたは Azure cloud) では、より多くのデータをサポートしており、同時ユーザー数が多いため、JET/ACE データベースエンジンよりも容量が大きくなっています。 このガイドでは、SQL Server の旅をスムーズに開始し、作成した Access のフロントエンドソリューションを維持して、将来のデータベースソリューションで Access を使用できるように motivates することができます。 アップサイジングウィザードが Access 2013 の Access から削除されたため、Microsoft SQL Server Migration Assistant (SSMA) を使用できるようになりました。 正常に移行するには、次のステージに従います。

SQL Server へのデータベース移行のステージ

始める前に

以下のセクションでは、作業を始めるのに役立つ背景とその他の情報を提供します。

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

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

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

SQL Server の利点

SQL Server に移行するには、いくつかの説得力が必要ですか? 次のような追加のメリットを検討してください。

  • 同時ユーザー数の増加    SQL Server は、複数のユーザーを追加するときに、Access よりも多くの同時実行ユーザーを処理することができます。

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

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

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

  • 即座の回復性    オペレーティングシステムがクラッシュしたり、電源が切れたりした場合、SQL Server は、データベースを一定の時間で自動的に一貫性のある状態に回復できます。また、データベース管理者の介在は必要ありません。

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

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

最適な Azure SQL Server オプションを選ぶ

Azure SQL Server に移行する場合は、次の3つのオプションから選ぶことができます。それぞれには、次のような利点があります。

  • 1つのデータベース/弾力性プール    このオプションには、SQL データベースサーバーによって管理される専用のリソースのセットがあります。 1つのデータベースは、SQL Server に含まれているデータベースに似ています。 エラスティックプールを追加することもできます。これは、SQL データベースサーバーで管理されているリソースセットで共有されたデータベースのコレクションです。 一般的に使用される SQL Server 機能は、組み込みのバックアップ、パッチ、および回復で利用できます。 ただし、完全なメンテナンス時間と、SQL Server からの移行が難しい場合があります。

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

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

詳細については、「 azure へのデータベース移行パスを選択する」および「 azure で適切な SQL Server オプションを選択する」を参照してください。

最初の手順

次のようないくつかの問題を解決して、移行プロセスを合理化してから、SSMA を実行することができます。

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

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

  • 添付ファイル列を削除する    SSMA は、添付ファイル列を含むテーブルを移行しません。

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

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

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

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

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

ヒント    最大 10 GB をサポートするデスクトップにMICROSOFT SQL Server Express editionをインストールすることを検討してください。また、移行の実行と確認には、無料で簡単に行うことができます。 接続するときに、データベースインスタンスとして LocalDBを使用します。

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

実行

Microsoft は、移行を容易にするためにMICROSOFT SQL Server Migration Assistant (ssma) を提供しています。 SSMA は主に、テーブルを移行し、パラメーターなしでクエリを選択します。 フォーム、レポート、マクロ、VBA モジュールは変換されません。 SQL Server メタデータエクスプローラーには、Access データベースオブジェクトと SQL Server オブジェクトが表示され、両方のデータベースの現在のコンテンツを確認できます。 この2つの接続は移行ファイルに保存され、将来、他のオブジェクトを移行することを決定します。

    データベースオブジェクトのサイズと、転送する必要があるデータの量によっては、移行プロセスに時間がかかる場合があります。

  1. SSMA を使ってデータベースを移行するには、まずダウンロードした MSI ファイルをダブルクリックしてソフトウェアをダウンロードしてインストールします。 お使いのコンピューターに適切な32または64ビットバージョンがインストールされていることを確認してください。

  2. SSMA をインストールした後は、必要に応じて、Access データベースファイルが保存されているコンピューターからデスクトップで開きます。

    共有フォルダー内のネットワークから Access データベースにアクセスできるコンピューターで開くこともできます。

  3. SSMA の最初の手順に従って、SQL Server の場所、移行する Access データベースとオブジェクト、接続情報、リンクテーブルを作成するかどうかなどの基本的な情報を入力します。

  4. SQL Server 2016 以降に移行していて、リンクテーブルを更新したい場合は、[レビューツール] > Project の設定>全般] を選んで、rowversion 列を追加します。

    Rowversion フィールドは、レコードの競合を回避するのに役立ちます。 Access では、SQL Server のリンクテーブルの rowversion フィールドを使って、レコードが最後に更新された日時を確認します。 また、クエリに rowversion フィールドを追加した場合は、更新操作の後に行が再選択されます。 これにより、書き込みの競合エラーを回避して、元の申請とは異なる結果が検出された場合に発生する可能性がある削除の問題を解決することができます。たとえば、浮動小数点値のデータ型と変更されたトリガーを変更します。行. ただし、フォーム、レポート、VBA コードで rowversion フィールドを使用することは避けてください。 詳細については、「rowversion」を参照してください。

        タイムスタンプで混乱を招く rowversion を避けます。 キーワード timestamp は、SQL Server の rowversion のシノニムですが、rowversion を使ってデータエントリのタイムスタンプを作成することはできません。

  5. 正確なデータの種類を設定するには、[レビューツール>プロジェクトの設定>入力マッピング] を選択します。 たとえば、英語のテキストしか保存していない場合は、 varcharではなく varchar を使用できます。

オブジェクトを変換する

SSMA Access オブジェクトは SQL Server オブジェクトに変換されますが、オブジェクトはすぐにはコピーされません。 SSMA には、移行対象の次のオブジェクトの一覧が用意されているため、それらを SQL Server データベースに移動するかどうかを決定できます。

  • テーブルと列

  • パラメーターを指定せずにクエリを選択します。

  • 主キーと外部キー

  • インデックスと既定値

  • 制約のチェック (ゼロの長さの列プロパティ、列の入力規則、テーブルの入力規則の許可)

ベストプラクティスとして、SSMA 評価レポートを使用して、エラー、警告、情報メッセージ、移行の実行の推定時間、および実際に移動する前に実行する個々のエラー修正手順などの変換結果を表示します。対象.

データベースオブジェクトを変換すると、Access のメタデータからオブジェクトの定義が処理され、同等のtransact-sql (t-sql) 構文に変換され、この情報がプロジェクトに読み込まれます。 Sql server または sql Azure Metadata Explorer を使用して、SQL Server または SQL Azure オブジェクトとそのプロパティを表示できます。

オブジェクトを変換、読み込み、SQL Server に移行するには、このガイドに従ってください。

ヒント    Access データベースを正常に移行したら、プロジェクトファイルを後で使用できるように保存します。これにより、テストまたは最終的な移行のためにデータをもう一度移行できます。

テーブルをリンクする

Windows に付属のネイティブ SQL Server ドライバーを使う代わりに、最新バージョンの SQL Server OLE DB および ODBC ドライバーをインストールすることを検討してください。 最新のドライバーだけでなく、以前のドライバーでは Azure SQL の新機能もサポートされます。 変換されたデータベースを使用する各コンピューターにドライバーをインストールできます。 詳細については、「 MICROSOFT OLE DB Driver 18 FOR Sql server 」および「 microsoft ODBC DRIVER 17 for sql server」を参照してください。

Access のテーブルを移行した後は、データをホストする SQL Server のテーブルにリンクすることができます。 Access から直接リンクすると、より複雑な SQL Server 管理ツールを使用するよりも簡単にデータを表示することができます。  SQL Server データベース管理者によって設定された権限に応じて、リンクされたデータのクエリと編集を行うことができます。

    リンク処理中に SQL Server データベースにリンクするときに ODBC DSN を作成する場合は、新しいアプリケーションを使用するすべてのコンピューターで同じ DSN を作成するか、DSN ファイルに保存されている接続文字列をプログラムで使用します。

詳細については、「 AZURE Sql Server データベースからデータをリンクまたはインポートする」および「 sql server データベースのデータをインポートまたはリンクする」を参照してください。

メモ   Access では、リンクテーブルマネージャーを使用して、テーブルの更新と再リンクを容易に行うことを忘れないでください。 詳細については、「リンクテーブルを管理する」を参照してください。

テストと改訂

以下のセクションでは、移行時に発生する可能性のある一般的な問題とその対処方法について説明します。

クエリ

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

データ型

Access と SQL Server のデータ型は似ていますが、次のような潜在的な問題に注意してください。

大きい数値    大きい数値データ型には、金額以外の数値が格納されており、SQL bigint データ型と互換性があります。 このデータ型を使うと、大きい数値を効率的に計算できます。ただし、64ビット版の Access では、16.0.7812 データベースファイル形式を使用する必要があります。 詳細については、「大きい数値データ型を使用する」と「 64 ビット版または32ビット版の Office を選択する」を参照してください。

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

日付と時刻    日付と時刻の考慮事項はいくつかあります。

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

  • Datetime よりも大きい日付範囲のdatetime2データ型を使用します。

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

    • 1/1/19 と1/31/19 の間に注文された日付には、すべての注文が含まれないことがあります。

    • 1/1/19 00:00:00 AM と 1/31/19 11:59:59 PM の間に注文された日付には、すべての注文が含まれます。

添付ファイル   添付ファイルデータ型は、Access データベースにファイルを保存します。 SQL Server では、いくつかのオプションを検討する必要があります。 Access データベースからファイルを抽出して、SQL Server データベース内のファイルへのリンクを保存することができます。 または、FILESTREAM、FileTables、または Remote BLOB store (RBS) を使用して、添付ファイルを SQL Server データベースに保存したままにすることもできます。

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

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

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

    複数値を持つフィールドは変換されず、Access 2010 で廃止されました。

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

Visual Basic

SQL Server では VBA はサポートされていませんが、次のような問題が発生する可能性があります。

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

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

パフォーマンスを最適化する

新しいバックエンド SQL Server を使ってパフォーマンスを最適化する最も重要な方法は、ローカルクエリとリモートクエリのどちらを使用するかを決定することです。 SQL Server にデータを移行する場合は、ファイルサーバーから、コンピューティングのクライアントサーバーデータベースモデルに移行することもできます。 次の一般的なガイドラインに従ってください。

  • クライアントで読み取り専用の小さなクエリを実行して、アクセスをすばやく許可します。

  • サーバーで長い読み取り/書き込みクエリを実行して、高い処理能力を利用します。

  • フィルターとアグリゲーションを使ってネットワークトラフィックを最小限に抑えて、必要なデータだけを転送します。

クライアントサーバーデータベースモデルのパフォーマンスを最適化する

詳細については、「パススルークエリを作成する」を参照してください。

次に、その他の推奨ガイドラインを示します。

ロジックをサーバーに配置する    また、アプリでは、ビュー、ユーザー定義の関数、ストアドプロシージャ、計算フィールド、トリガーを使って、アプリケーションロジック、ビジネスルールとポリシー、複雑なクエリ、データの入力規則、および参照整合性コードを一元的に共有することもできます。クライアントではなく、サーバー。 このクエリまたはタスクは、サーバー上で適切かつ迅速に実行できるかどうかを確認します。 最後に、各クエリをテストして最適なパフォーマンスを確保します。

フォームおよびレポートでビューを使用する    Access で、次の操作を行います。

  • フォームの場合は、読み取り専用フォーム用の SQL ビューと、レコードソースとして読み取り/書き込みフォーム用の SQL インデックスビューを使用します。

  • レポートの場合は、レコードソースとして SQL ビューを使用します。 ただし、レポートごとに個別のビューを作成すると、他のレポートに影響を与えることなく、特定のレポートをより簡単に更新できるようになります。

フォームまたはレポートにデータを読み込むのを最小限に抑える    ユーザーが要求するまで、データを表示しないでください。 たとえば、"recordsource/レコードソース" プロパティは空白のままにして、ユーザーがフォームでフィルターを選択できるようにしてから、"recordsource/レコードソース" プロパティにフィルターを設定します。 または、DoCmd と DoCmd の where 句を使用して、ユーザーが必要としている正確なレコードを表示します。 レコードナビゲーションをオフにすることを検討してください。

異種クエリに注意する   ローカルの Access テーブルと SQL Server のリンクテーブルを結合するクエリを実行しないようにします (ハイブリッドクエリとも呼ばれます)。 この種類のクエリでは、すべての SQL Server データをローカルコンピューターにダウンロードし、クエリを実行しても、SQL Server でクエリは実行されません。

ローカルテーブルを使用する状況    国または地域の州または県の一覧のように、ほとんど変更されないデータに対してローカルテーブルを使うことを検討してください。 静的なテーブルは、フィルター処理に使用されることが多くあり、Access のフロントエンドでもパフォーマンスが向上します。

詳細については、「データベースエンジンチューニングアドバイザー」、「パフォーマンス最適化ツールを使用して access データベースを最適化する」、「 SQL Server にリンクされている Microsoft Office Access アプリケーションの最適化」を参照してください。

関連項目

Azure Database Migration Guide

Microsoft データ移行のブログ

SQL Server の移行、変換、アップサイジングhttps://www.fmsinc.com/consulting/sqlserverupsizing.aspxへの Microsoft access

Access デスクトップ データベースを共有する方法

注:  このページは、自動翻訳によって翻訳されているため、文章校正のエラーや不正確な情報が含まれている可能性があります。 私たちの目的は、このコンテンツがお客様の役に立つようにすることです。 情報が役に立ったかどうか、ご意見をお寄せください。 参考までに、こちらから英語の記事をお読みいただけます。

Office のスキルを磨く
トレーニングの探索
新機能を最初に入手
Office Insider に参加する

この情報は役に立ちましたか?

ご意見をいただきありがとうございます。

フィードバックをお寄せいただき、ありがとうございます。Office サポートの担当者におつなぎいたします。

×