8

現在、複数の (同じスキーマの) Access 2003 データベースがラップトップで使用されているという問題があります。

データを中央アクセス データベースに自動的に同期する方法を見つける必要があります。

ラップトップ上のデータは追加されるだけなので、更新/削除操作は問題になりません。

これを簡単に行えるツールはどれですか? 最適なツールまたはソリューションの決定に影響を与える要因は何ですか?

4

7 に答える 7

6

Accessに組み込まれているJetレプリケーションを使用することは可能ですが、警告します。かなり不安定です。また、キーの衝突を回避するためにランダムな符号付き整数を選択するため、どのテーブルでもPKが台無しになります。そのため、特定のレコードの次のPKとして-1243482392912になる可能性があります。これは、何らかの種類のルックアップ（顧客ID、注文番号など）を実行している場合に入力するPITAです。Accessの同期を自動化することはできません（VBAを使用してそのようなものを偽造することはできますが、それでも、データベースが開かれている場合にのみ実行されます）。

私がお勧めする方法は、「中央」データベースでSQL Server 2005/2008を使用し、「リモート」データベースのバックエンドとしてSQL Server Express Editionsを使用してから、Accessのリンクテーブルを使用してこれらのSSEEデータベースに接続することです。それらを同期するためのレプリケーション。「中央」データベースをパブリッシャーとして、SSEEデータベースをサブスクライバーとして、マージレプリケーションまたはスナップショットレプリケーションを設定します。Access Jetレプリケーションとは異なり、PKの番号付けを制御できますが、サブスクライバーが変更をプッシュしないため、これは問題になりません。

SQL Serverがもたらすスケーラビリティに加えて、Windows同期マネージャーを使用してこれを自動化することもできます（同期フォルダーがある場合は、ログオン/ログオフ時にポップアップして同期する厄介な小さなボックスです）。所定の間隔、起動時、シャットダウン時、または時刻、および/またはコンピューターがアイドル状態のときに同期するか、オンデマンドでのみ同期します。Accessが1か月間実行されていなくても、ユーザーがネットワークに接続するたびにそのデータセットを更新できます。とてもかっこいいもの。

于 2009-11-26T15:22:45.487 に答える
6

アクセス レプリケーションは厄介な場合があり、いくつかのチェックを伴う追加クエリのみが必要なため、自分で何かを作成することをお勧めします。各ラップトップで収集されたデータが重複できない場合、これはそれほど難しくありません。

主キーを考慮する必要があります。レコードが正しく関連付けられるように、キーにユーザー名またはラップトップ名を組み込むことをお勧めします。

于 2009-11-26T09:36:56.577 に答える
4

このスレッドの回答は、明らかに Jet Replication を使用したことがなく、聞いたことを繰り返している人や、アプリケーションの設計エラーを実際に反映する問題を Jet Replication に帰している人々からの、Jet Replication に関する誤った情報でいっぱいです。

Access に組み込まれている Jet レプリケーションを使用することは可能ですが、注意してください。

Jet Replication は不安定ではありません。他の複雑なツールと同様に、適切に使用すれば完全に信頼できます。レプリケートされていないデータベースでは問題を引き起こさない特定の事柄が、レプリケートされたときに問題を引き起こす可能性があることは事実ですが、データベース エンジンによるレプリケーションの性質上、これは当然のことです。

また、キーの衝突を回避するためにランダムな符号付き整数を選択するため、どのテーブルでも PK が台無しになります。そのため、特定のレコードの次の PK として -1243482392912 になる可能性があります。これは、何らかの検索を行う場合に入力する PITA です (顧客 ID、注文番号など)。

サロゲート オートナンバー PK は、最初からユーザーに公開されるべきではありません。これらは、舞台裏でレコードを結合するために使用される無意味な数値であり、ユーザーにそれらを公開している場合は、アプリケーションの設計に誤りがあります。

シーケンス番号がどうしても必要な場合は、自分で作成し、レプリカ間の衝突を防ぐ方法の問題に対処する必要があります。しかし、これはどのデータベース エンジンでもレプリケーションの問題です。SQL Server は、データベース エンジン レベルで個々のレプリカにシーケンス番号のブロックを割り当てる機能を提供します。これは非常に優れた機能ですが、複数の SQL Server インスタンスを維持することによる管理オーバーヘッドが増加するという犠牲が伴います (すべてのセキュリティとパフォーマンスの問題を伴う)。それが伴う）。Jet レプリケーションでは、これをコードで行う必要がありますが、それは複雑な問題ではありません。

もう 1 つの方法は、1 つの列がソース レプリカを示す複合 PK を使用することです。

しかし、これは Jet のレプリケーションの実装に問題があるわけではありません。意味のあるシーケンス番号が必要なレプリケーション シナリオでは問題になります。

Access の同期を自動化することはできません (VBA を使用して似たようなものを偽装できるかもしれませんが、データベースが開かれている場合にのみ実行されます)。

これは明らかに誤りです。Jet Synchronizer をインストールすると、同期 (直接、間接、またはインターネット同期) をスケジュールできます。それがなくても、VBScript を定期的に実行して同期を行うようにスケジュールできます。これらは、Access アプリケーションを開かずに自動化された Jet 同期を実現する 2 つの方法にすぎません。

MS ドキュメントからの引用:

Jet オブジェクトとレプリケーション オブジェクトを使用する

JRO は、Jet レプリケーションを管理する最良の方法ではありません。1 つには、DAO 自体に欠けている機能が 1 つだけあります。つまり、コードで間接的な同期を開始する機能です。ただし、アプリに依存関係を追加する場合 (JRO には参照が必要であるか、遅延バインディングを介して使用できます)、Jet レプリケーションを制御するための真に有用なライブラリへの依存関係を追加することもできます。それがTSI Synchronizerです。は、Jet Replication の世界有数の専門家であった Michael Kaplan によって作成されました (その後、専門分野として国際化に移行しました)。これにより、同期のスケジュール設定、あらゆる種類の同期の開始、非常に必要とされている MoveReplica コマンド (レプリケーションを中断せずにレプリカを移動または名前変更する唯一の合法的な方法) など、Jet が公開するほぼすべてのレプリケーション機能をプログラムで完全に制御できます。

JRO は、中止された Microsoft の ADO-Everywhere キャンペーンの醜い継子の 1 つです。その目的は、Jet 固有の機能を提供して、ADO 自体でサポートされている機能を補うことです。ADO を使用していない (そして、Jet バックエンドを備えた Access アプリを使用すべきではない) 場合は、JRO を実際に使用する必要はありません。上で述べたように、DAO でまだ使用できない機能 (つまり、間接同期の開始) を 1 つだけ追加します。Microsoft は、Jet 固有の機能用のスタンドアロン ライブラリを作成し、選択した場合にサポートできたはずの信じられないほど便利な機能をすべて意図的に除外したことで、悪意を持っていたと思わずにはいられません。

上記の回答の誤った主張を処理したので、ここに私の推奨事項を示します。

追加専用のインフラストラクチャがあるため、@Remou が推奨していることを実行し、必要な場所に新しいレコードを手動で送信するように設定します。そして、Jet レプリケーションを使用した場合と同様に、PK の問題に対処する必要があるという彼の意見は正しいです。これは、複数の場所に新しいレコードを追加する必要があるためであり、すべてのレプリケーション/同期アプリケーションに共通です。

ただし、1 つの注意点: 将来、追加のみのシナリオが変更された場合、最初からやり直すか、大量の毛むくじゃらのコードを作成して削除と更新を管理する必要があります (これは簡単ではありません。信じてください。やったぜ！）。Jet レプリケーションのみを使用する利点の 1 つは (双方向の同期、つまり複数の場所での編集に最も価値がありますが)、追加のみのシナリオを問題なく処理し、完全なマージ レプリケーションを簡単に処理できることです。将来の要件。

最後に、Jet Replication を始めるのに適した場所は、Jet Replication Wikiです。リソース、ベスト プラクティス、信じられないことのページは、おそらく開始するのに最適な場所です。

于 2009-11-26T23:15:56.117 に答える
1

そこにいくつかの情報があるので、AccessDatabaseReplicationを読む必要があります。

ただし、アプリケーションで正しく機能するには、その目的で使用できるメソッドとプロパティを使用してカスタムメイドのソリューションを展開する必要があると思います。

Microsoft Accessデータベース（.mdbファイルのみ）に設定されたレプリカのメンバー間でのデータおよび設計情報の交換をプログラムで制御する必要がある場合は、JetおよびReplication Objects（JRO）を使用します。たとえば、JROを使用して、ユーザーがデータベースを開いたときに、ユーザーのレプリカをセットの残りの部分と自動的に同期するプロシージャを作成できます。プログラムでデータベースを複製するには、データベースを閉じる必要があります。

データベースがMicrosoftAccess97以前で作成されている場合は、データアクセスオブジェクト（DAO）を使用して、プログラムでデータベースを複製および同期する必要があります。

DAOのメソッドとプロパティを使用して、以前のバージョンのMicrosoftAccessでレプリケートされたデータベースを作成および維持できます。レプリカセットのメンバー間でのデータと設計情報の交換をプログラムで制御する必要がある場合は、DAOを使用してください。たとえば、DAOを使用して、ユーザーがデータベースを開いたときに、ユーザーのレプリカをセットの残りの部分と自動的に同期するプロシージャを作成できます。

次のメソッドとプロパティを使用して、レプリケートされたデータベースを作成および維持できます。

  • MakeReplica方法
  • Synchronize方法
  • ConflictTable財産
  • DesignMasterID財産
  • KeepLocal財産
  • Replicable財産
  • ReplicaID財産
  • ReplicationConflictFunction財産

Microsoft Jetは、部分的なレプリカ（完全なレプリカのレコードのサブセットを含むレプリカ）を作成および維持するための次の追加のメソッドとプロパティを提供します。

  • ReplicaFilter財産
  • PartialReplica財産
  • PopulatePartial方法

ドキュメントのデータの同期の部分を必ずお読みください。

于 2009-11-26T06:00:24.993 に答える
0

a07 へのアップグレードを余儀なくされるまで (それがなくなったとき)、私は何年も a00 でレプリケーションを使用していました。エンタープライズ レベルで遭遇した最も問題のある問題は、CONFLICTSの管理でした。タイムリーに管理されていなかったり、数が多すぎたりすると、ユーザーはイライラし、データの信頼性が低下します。

リモート サイトが常にインターネットに接続されているとは限らない場合でも、レプリケーションはうまく機能しました。これにより、データを操作し、可能な場合は同期することができました。少なくとも 1 日 2 回。

同期を管理するリモート コンピューターに別のデータベースをインストールしたため、ユーザーはデスクトップ上のアイコンをクリックするだけで同期を呼び出すことができました。

ユーザーには、レガシー システムから更新される指定された FTP ファイルからフィードをプッシュ/プルする別のボタンがありました。

このプロセスは非常にうまく機能しました。30 のこれらの「ノード」が全国で機能し、データを管理し、FTP サーバーに更新していたからです。

このパスを真剣に検討している場合は、お知らせください。ドキュメントをお送りします。

于 2014-09-24T23:04:34.043 に答える
-2

FWIW:

  1. 自動採番。私はデビッドに同意します-それらは決して公開されるべきではありません。その誘惑を取り除くために、ランダム自動番号を使用します。
  2. 複製。私はこれを数年前に広範囲に使用し、同期をスケジュールし、GUID を PK として使用しました。ネットワーク上で問題が発生するとレプリカが破損し、データを回収してレプリカを再発行しなければならないことが何度もありました。痛い！
于 2009-11-28T00:15:25.470 に答える
-2

ラップトップに接続する独自の同期ソフトウェアを作成して、そのデータベースから差分を選択し、それをマスターに挿入できます。この操作がどれほど簡単かは、データスキームによって異なります。(FK を含むテーブルが多数ある場合は、賢く行う必要があります)。自分で書いた方が効率的だと思います。

この種の動作を自動化することはレプリケーションと呼ばれ、Accesss はそれをサポートしているようですが、実装されているのを見たことがありません。

ほとんどの場合、ラップトップはメイン DB に接続されていないと思いますが、(データを複製するために) とにかく良い考えではありません。

それを行うためのサードパーティのツールを探す場合は、コピーする前にテーブル間の差分を簡単に行うことができ、もちろん段階的に行うことができるものを探してください。

于 2009-11-26T05:19:06.107 に答える