2

「実世界」でこれを試す前に、いくつかのテストを行うために、SQL Server 2005 Express を自分のコンピューターで起動して実行することができました。

ユーザー インターフェイスとして "フロント エンド" を保持する SQL Server に移行する必要がある、かなり大きな MS Access 2007 データベース アプリケーションがあります。（アプリはすでにフロントエンドとバックエンドを持つ「分割」データベースです....）

SSMA を使用して Access データベースを SQL Server Express に移行するための初期テストをいくつか行いました。

明らかに私はいくつかのことを理解していません。

概念的には、サーバー上にあるデータベースのバックエンドを SQL サーバーに移行し、フロントエンドをバックエンドの (現在は SQL にリンクされている) テーブルに再リンクする必要があると考えました。

SSMA を使用してこれを行うと、"SSMA$myTableNameHere$local" のような名前のテーブルがバックエンド アクセス ファイルに作成されます。また、ODBC リンク テーブルとして表示される元のテーブル名も取得します。

ここまでは順調ですね。

しかし....フロントエンド（ユーザーインターフェイス）からリンクされたテーブルを再構築しようとすると、元のテーブル名ではなく「SSMA $ myTableNameHere $ local」という名前が表示されます（現在はODBC経由でリンクされています） 「SSMA、、、、」テーブルにリンクできますが、それは、すべてのクエリ、すべてのフォーム、およびフロント エンドのすべてのコードで、すべてのテーブルの名前を変更することを意味します。私が本当にやりたいことではありません。

それで....

FRONT END を移行して、何が起こるか見てみようと思いました。

私が最終的に得たのは、基本的には機能する状況です（データの欠落など、まだ見ていない重大なエラーや問題がいくつかあります!!!!）、それでも「SSMA $myTableNameHere$local" テーブルと、元の名前を持つ ODBC リンク テーブル。

理解しようとしているのですが……これは、フロントエンドで移行を行い、同じファイルを各ユーザーのコンピューターにコピーするだけということですか?

私が少し混乱しているもう 1 つの問題は、ODBC 経由でローカル マシン (つまり、私のコンピューター) 上の SQL Server Express にリンクできないため、バックエンドの移行をテストしてから、フロント経由でテーブルにリンクすることをテストできないことです。クライアント/サーバーの状況で過去に行ったように終了します。

4

6 に答える 6

2

SSMA がバック エンドのテーブルを SQL Server へのリンクに置き換えると仮定すると、フロント エンドの元のテーブル リンクを削除し、新しく作成したテーブル リンクをバック エンドからインポートするだけで済みます。バックエンドはもはや何にも使用されないため、破棄できます。

于 2009-03-02T23:34:47.420 に答える
1

[エクスポート] を選択し、ドロップダウン リストから [ODBC] を選択し、[データ ソース] ウィンドウからデータ ソースを選択します。作成したデータ ソースを選択し、[OK] をクリックします。SQL Server を SQL Management Studio Express で使用します。すべての日付には定型入力が必要です。すべてのテキストとメモには Allow Zero Length =Yes が必要です 結局、Access バックエンドからすべてのリンクを切断し、SQL.RENAME からすべての新しくリンクされたテーブルを古い名前にリンクを確立します。新しいことをするまでは、フロントエンド ユーザー インターフェイスを使用します。

于 2011-07-19T19:39:01.697 に答える
0

odbcを使用する場合、SSMAの使用は異なります。フルアクセス（バックエンドとフロントエンド）を使用するアプリケーションがある場合。DAOなどを使用して、フォームを簡単にバインドするオブジェクトを問題なく操作できます。データベースをSQLサーバーに移行する必要がある場合は、odbc（テーブルをSQLサーバーにリンクすることにより）、ssma、...主な問題を直接使用できます。制限されたフォーム、クエリ、コードをクライアント側で保持する方法。Uが直接odbcを使用する場合は、すべてのオブジェクトを自分で再リンクしてコードを変更する必要がありますが、ssmaを使用する場合は、何もする必要はありません。以前と同じように作業を続けます。SSMAの問題は、別のSQLサーバーを使用して別の場所でクライアント側を開発した場合に、フロントエンドをクライアントに展開する方法です。

于 2009-03-28T10:34:29.107 に答える
0

Acronym Soup の知識が不足していることをお許しください。SSMA は、SQL Server 2005 の "データのインポート ウィザード" または Access のウィザードで、データを SQL Server に送信するものだと思います。Access から SQL Server にデータを送信したようです。これは望ましくありません。SQL Server の DTS (現在は SSIS などと呼ばれていますか?) を使用して、データを SQL Server にインポートしたいと考えています。次に、SQL Server にテーブルを作成します。次に、SQL Server の DSN エントリを作成し、テーブルを再リンクするだけです。すべてがうまくいくはずです。

全体として、一般的なルールは、Access を使用してデータを SQL Server に送信するのではなく、SQL Server を使用して Access テーブルをインポートすることです。

于 2009-03-02T22:32:55.370 に答える
0

率直に言って、移行が完了したので、テーブルの設計を確認する必要があります。私の経験では、Access 移行のウィザードが正しいデータ型を選択するのがうまくいきません。たとえば、メモ フィールドがある場合は、代わりに varchar フィールドを簡単に使用できますが、私が最後に使用したウィザード (以前のバージョン) では常にテキスト フィールドに変換されていました。過去にその間違いがあった場合は、日付フィールドを文字ベースではなく日時にするなど、いくつかの修正を検討する時期でもあります。

私はウィザードを使ってデータ移行を行うことを二度と考えません。

また、データを SQL Server に変換するだけでは、多くの場合、実際にパフォーマンス上の利点を得るには不十分であることがわかります。すべてのクエリをテストし、クエリが遅い場合は代わりにストアド プロシージャに変換できるかどうかを検討する必要があります。Jet SQL から T-sql への変換をなくすことで、パフォーマンスが向上する可能性があります。さらに、t-sql には、Access にはないパフォーマンスを向上させる多くの機能があります。Access はパフォーマンス チューニングに大きく影響しませんが、SQL Server バックエンドでパフォーマンス チューニングのメリットを得るには、SQL Server 固有のクエリを作成する必要があります。Access テーブルのインデックスが適切に作成されていない場合は、インデックス作成を考慮する必要があります。

于 2009-03-10T18:10:18.820 に答える
0

私なら我慢して、SQLServer 側のテーブルの名前を、元のデータベースにあったわかりやすい名前に戻します。おそらく問題は少ないでしょう。特に、MS Access 側にコードが埋め込まれている場合。

MS Access 側を展開する方法に関しては、ユーザーのワークステーションに ODBC リンクを作成し、MS Access ファイルをデスクトップにコピーする必要があります (ただし、MDE (または 2007 に相当するもの) を作成することをお勧めします)。 ) 誤って壊してしまわないように)。

于 2009-03-10T18:01:15.143 に答える