2

Access (2003) から SQL Server DB (2005 または 2008) への移行を自動化する必要があります。アップサイジングは、ビルド プロセスの一部として自動的に実行する必要があります。

ソフトウェアにはシングル ユーザー リッチ クライアントと Web バージョンの 2 つのバージョンがあるため、これが必要です。Access DB は単一ユーザーがセットアップ作業を最小限に抑えるために使用され、SQL Server は多くの同時ユーザーでパフォーマンスとスケーリングを向上させるために使用されます。Access は「主要な」DB である必要があります。つまり、開発者は Access DB で変更を行い、それらはビルド プロセス内で SQL サーバーに伝達されます。多くの変更が発生するため、手動で行うことはできません。

私はマイクロソフトの世界に慣れていないので、そのための適切なツールを知りません。どのツールをどのように使用できますか? アップサイジング アシスタントを使用して (クリックして) それを行う方法を知っています。おそらく、どうにかしてそれを自動化できますか?

ご回答ありがとうございます。乾杯、アルネ

4

2 に答える 2

2

Access データベースに SQL Server バックエンドを使用しないのはなぜですか? その後、変更は一度だけ行われ、すべてが同期されます。

于 2010-06-07T18:35:09.870 に答える
0

ここでの問題は、2 つの異なるシステムでバージョン管理を行おうとしていることです。

すべての設計変更を Access で行うことができる場合は、単純にそれを SQL Server に拡大できます。ここでの問題は、既存の SQL Server データベースを変更する必要があるかどうかです。そして、これは時間の経過とともに必要ですか?Access データベースをアップサイジングすると、新しいバージョンが SQL Server まで取得されますが、既存の SQL Server データベースには役立ちません。

時間の経過とともに両方のシステムと既存のシステムのテーブルを変更する必要がある場合は、アクセス開発者に、テーブルへのすべての変更を ddl sql として記述する必要があると述べます。次に、Access で実行された ddl を使用して変更を行います。開発者はその時点で、同じ ddl を取得して SQL 側で実行する必要があります。少し修正が必要かもしれません。彼らはそれを修正して、SQLサーバーで実行します。したがって、2 つのスクリプトが作成されます。1 つは SQL サーバー用、もう 1 つは Access 用です。アクセスの場合、数行のコードを記述して、ddl のテキスト ファイルを読み取って処理できます。(すべてのスクリプトに同じコードを使用できます)。

このようにして、アップグレードごとに同等の変更セットを構築します。したがって、アクセス テーブルに直接設計変更を加えることは絶対に許可しないでください。テーブル デザイナーでデザインの変更を許可すると、どの変更を SQL Server に引き継ぐ必要があるかがわからないため、大きな問題が発生します。

ただし、推奨されるアプローチとして、テーブルの設計変更はSQLサーバーで最初に行うことをお勧めします。その理由は、SQL ビジュアル スタジオ ツールのテーブル デザイナーにより、行ったばかりの変更をクリップボードにスクリプト化 (単純な右クリック) できるからです。もう 1 つの理由は、テーブル デザイナーがアクセス デザイナーと非常によく似ていることです。そのため、これは、SQL サーバーの経験がほとんどないアクセス開発者でも簡単に使用できます。そのため、「クリップボードへのスクリプトの変更」を右クリックするだけで、SQL Server の必要な変更スクリプトが作成されます (SQL Server のファイルに保存されます)。次に、ddl を取得し、アクセス側で実行します。これは、ddl に Access 用の若干の変更が必要になる可能性があるためです (ただし、ddl ステートメントを記述する必要はありませんでした)。したがって、これは ddl がそれらのために書き込まれることを意味します。これは、SQL サーバーの ddl が正しいことを知っていることを意味します。次に、単にその ddl を取得し、再度使用してアクセス テーブルも変更します。ddl はアクセスのためにわずかな変更が必要になる場合がありますが、テーブルの変更が必要であり、単純なテーブルの変更が行われるまでこれを実行して修正する必要があるため、それで問題ありません。したがって、このスクリプト化された ddl は、アクセスの更新のためにファイルにも保存されます。ddl スクリプトは、アクセスのために若干の変更が必要になる可能性があるため、このアプローチが最適だと思います。これが変更/修正されている限り、問題はありません。したがって、このスクリプト化された ddl は、アクセスの更新のためにファイルにも保存されます。ddl スクリプトは、アクセスのために若干の変更が必要になる可能性があるため、このアプローチが最適だと思います。これが変更/修正されている限り、問題はありません。したがって、このスクリプト化された ddl は、アクセスの更新のためにファイルにも保存されます。ddl スクリプトは、アクセスのために若干の変更が必要になる可能性があるため、このアプローチが最適だと思います。これが変更/修正されている限り、問題はありません。

そのため、一定期間の変更を行うと、両方のシステムの変更を同期する 2 つのスクリプトが作成されます。

既存の sql およびアクセス データベースを変更する必要がない場合は、アクセス権を持つ人々に任せてから、データベース全体を 1 回で sql サーバーにサイズアップするだけで完了です。

上記の両極端の間の他のアプローチについては、あまり考えられません。

ユーザーにアクセス権を変更してもらい、SQL Server に移動して SQL テーブルの設計を変更し、SQL Server 変更スクリプトを保存することができます。ただし、これではアクセス側の変更スクリプトは得られません。アクセス側に変更スクリプトが必要ない場合は、SQL Server 変更スクリプトを取得するので、これは非常にうまく機能します。

上記は私がこれに取り組む方法であり、それは非常に実行可能です...

于 2010-06-07T18:31:58.510 に答える