6

ここで覚えておいてほしいのは、私は Access の専門家ではないということです。私は SQL Server と .Net フレームワークに精通しています。これが私の状況です:

非常に大規模な MS Access 2007 アプリケーションが、請負業者によって私の会社のために構築されました。

アプリケーションはアクセスによって 2 つの層に分割されています。すべての Ms Access フォームを保持するフロント エンド部分と、ネットワーク上のコンピュータに格納されるアクセス テーブル、クエリなどであるバック エンド部分があります。

もちろん、Ms Access に組み込まれたこれらすべての GUI フォームを維持しながら、データ ストレージ部分を SQL Server 2005 に変換する必要があります。これが私の出番です。

少し読んだところ、フォームやアクセス テーブルを SQL Server テーブルにリンクできることがわかりましたが、正確に何ができるのか、どうすればよいのか、まだよくわかりません。

誰かがこれをしましたか?そのような取り組みに関する機能、制限、考慮事項についてコメントしてください。ありがとう!

4

8 に答える 8

3

Jet バックエンドを SQL Server にアップサイジングし、ODBC 経由でリンクすることを提案する人もいます。理想的な世界では、アプリは何も変更する必要なく美しく機能します。

現実の世界では、Jet バックエンドで効率的かつ高速になるように設計されたフロントエンド オブジェクトの一部が、実際にはサーバー データベースではうまく機能しないことがわかります。時々、Jet は間違った推測をして、本当に非効率的なものをサーバーに送信します。これは、レコードの大量更新の場合に特に当てはまります。サーバー リソースを占有しないようにするため (良いことです)、Jet はレコードごとに 1 つの UPDATE ステートメントを送信します (これはアプリにとっては悪いことです。単一の UPDATE ステートメントよりも遅い)。

あなたがしなければならないことは、アプリをサイズアップした後にアプリ内のすべてを評価し、パフォーマンスの問題がある場合は、ロジックの一部をサーバーに移動することです。これは、サーバー側のビューをいくつか作成するか、パススルー クエリを使用するか (SQL ステートメント全体を SQL Server に渡し、Jet が気にしないようにするため)、またはサーバー上にストアド プロシージャを作成する必要があることを意味します (特に更新操作の場合)。

しかし、一般的には、そのほとんどが変更なしで正常に機能すると想定するのは、実際には非常に安全です。古い Access/Jet アプリほど高速ではない可能性がありますが、そこで SQL プロファイラーを使用して何が問題なのかを把握し、再構築して SQL Server バックエンドでより効率的にすることができます。

Access アプリが既に効率的に設計されている場合 (たとえば、フォームが完全なテーブルにバインドされることはなく、代わりに 1 つまたはいくつかのレコードのみを返す制限的な WHERE 句を持つレコードソースにバインドされている場合)、おそらくうまく機能します。一方、Access のサンプル データベースとテンプレートに見られる悪い慣行を多く使用すると、大きな問題が発生する可能性があります。

すべての Access/Jet アプリは、いつかサーバー バックエンドを使用するようにアップサイジングされるという考えで最初から設計されるべきであるというのが私の意見です。これは、Access/Jet アプリが実際には非常に効率的で高速であることを意味しますが、アップサイズを行うと、最小限の痛みが発生することも意味します.

于 2009-02-19T03:16:13.367 に答える
3

いくつかのオプションがあります。アップサイジング ウィザードは、構造とデータをアクセスから SQL に移動する適切な (ish) ジョブを実行します。次に、リンクされたテーブルをセットアップして、アプリケーションが現在とほぼ同じように機能するようにすることができます。残念ながら、Access で使用される Sql 方言は Sql Server とは異なるため、コードに「生の SQL」ステートメントがある場合は、それらを変更する必要がある場合があります。

Access の他のすべての機能をテーブルにリンクしたので、QBE、フォームなどは期待どおりに動作するはずです。これが最も簡単で、おそらく最良のアプローチです。

問題にアプローチする別の方法は、上記のようにデータを移行し、リンクされたテーブルを使用するのではなく、アクセス内から ADO を利用することです。他の言語/開発環境に慣れている場合、そのアプローチはおなじみですが、それは間違ったアプローチです。Access には、データの操作を非常に簡単にする多くの組み込み機能が付属しています。ADO/Sql の使用に戻ると、これらの利点の多くが失われます。

アプリケーションの小さな部分 (必須ではないデータ) から始めて、いくつかのテーブルを移行し、それがどうなるかを確認することをお勧めします。もちろん、最初にすべてをバックアップします。

幸運を

于 2009-02-18T01:12:38.977 に答える
2

これが最も低コストのオプションです。SQL Server を指す Access クライアント用の ODBC 接続をセットアップする必要があります。次に、(私が思うに)「インポート」オプションを使用して、ODBC ソースを介してテーブルを SQL Server に「リンク」できます。Access テーブルから SQL Server にデータを移行すると、管理およびバックアップできる形式で SQL Server にデータが保存されます。重要なことは、クエリを SQL Server にビューとして記述し、Access データベースにリンク テーブルとして表示することもできるということです。

于 2009-02-18T01:11:52.940 に答える
0

この Access to SQL Server 移行ツールをご覧ください。これは、純粋な Web アプリケーションとして実行される、唯一ではないにしても、真のピア ツー ピアまたはサーバー ツー サーバー移行ツールの 1 つかもしれません。ほとんどの場合、ASP 3.0、XML、ファイル システム オブジェクト、データ ディクショナリ オブジェクト、ADO、ADO 拡張機能 (ADOX)、ディクショナリ スクリプト オブジェクト、およびその他の優れた Microsoft の技術とテクノロジがいくつか使用されています。あるサーバーにソース アクセス テーブルがあり、別のサーバーまたは同じサーバーに宛先 SQL Server があり、これを Web インターネット ソリューションとして実行したい場合、この製品が最適です。この例では、VPASP ショッピング カートについて説明しますが、Access のすべてのバージョンと、SQL 2000 から SQL 2008 までの SQL Server のすべてのバージョンで機能します。

VPASP ショッピングまたはその他のアクセス システム内のアクセス テーブル、ビュー、およびインデックス構造を SQL Server 2005/2008 に相当するものに自動変換する、一般的なデータベース アップグレード変換プロセスの開発を終えています。外部スタッフやコンサルタントからの外部支援を必要とせずに、サーバーから直接実行されます。

SQL Server で Access テーブル、インデックス、およびビューのクローンを作成した後、このデータ移行ルーチンは、Access テーブルから新しい SQL Server 2005/2008 テーブルにすべてのデータを選択的に移行します。実際の Access データベースまたはテーブルの内容またはパスワードを誰にでも。

これは、システム受け入れテストとして行われている、ほぼ 200 のテーブルとほぼ 300 のインデックスとビューを持つシステムに対して実行されるプロセスのリバース エンジニアリングの部分です。まだ進行中の作業ですが、コア部分は整っています。

http://www.21st Centuryecommerce.com/SQLDDL/ViewDBTables.asp

Access Table DDL (データ定義言語) の自動リバース エンジニアリングを行い、それらを SQL の同等の DDL ステートメントに変換します。これは、VPASP の顧客ごと、および VP-ASP のバージョンごとに、テーブル構造や追加のテーブルでさえわずかに異なる可能性があるためです。 .

ビューやインデックスを含むこれらの新しい SQL テーブルが作成された後、データを Access から SQL Server に移行する実際のデータ変換ルーチンを終了しています。VB スクリプト、ファイル システム オブジェクト (FSO)、ディクショナリ オブジェクト、XML、DHTML、JavaScript を使用して完全に ASP で記述されており、SQL Server 2008 データベースに対して実行されるように、非常に高速に実行されます。例。

ほぼ 500 の異なるデータベース オブジェクトをリバース エンジニアリングするには、おそらく 15 ~ 20 秒かかります。この例では、170 のテーブルと 270 のインデックスが含まれるため、合計で 2,000 を超える列が含まれる可能性があります。

アクセス システムと SQL Server システムで入力された注文が実際のカットオーバーの前に同じ結果を生成することを確認するためだけに、同じサーバー上で 2 つの異なるデータベース接続ファイルを使用して、両方の VPASP システムを並行して実行する方法を考え出しました。生産へ。

John (a/k/a The SQL Dude) sales@designersyles.biz (これは VP-ASP デモ サイトです)

于 2009-09-17T05:24:18.663 に答える
0

Linked Access テーブルは正常に動作しますが、ODBC およびその他のデータベース (Firebird、MySQL、Sqlite3) でしか使用していません。主キーまたは外部キーに関する情報が通過していませんでした。データ型の解釈にも問題がありました。MySQL の日付は、Access VBA の日付と同じではありません。SQL Server を使用している場合、これらの問題はそれほど深刻ではないと思います。

于 2009-02-18T01:12:08.510 に答える