Datenbank-Synchronisation - MS Access

https://stackoverflow.com/questions/1801658

05-07-2019
|

Frage

Ich habe ein Problem in dem Moment, wo mehrere (gleiches Schema) Access 2003 Datenbanken auf Laptops verwendet werden.

Ich brauche einen automatisierten Weg zu finden, um die Daten in eine zentrale Access-Datenbank zu synchronisieren.

Daten auf den Laptops ist nur angehängt, so aktualisieren / löschen Operationen wird nicht ein Problem sein.

Welche Werkzeuge wird mir erlauben, dies leicht zu tun? Welche Faktoren werden die Entscheidung über das beste Werkzeug oder Lösung aus?

Lösung

Es ist möglich, die Jet-Replikation in Access gebaut zu verwenden, aber ich werde Sie warnen, es ist ziemlich flockig. Es wird auch mess up Ihre PK auf, was Tabellen Sie es tun auf, weil es zufällig unterzeichnet Zahlen nimmt, um zu versuchen und Schlüssel Kollisionen zu vermeiden, so dass Sie vielleicht mit -1243482392912 als Ihr nächsten PK auf einem bestimmten Datensatz am Ende. Das ist ein PITA geben, wenn Sie jede Art von Lookup es tun (wie eine Kundennummer, Auftragsnummer, etc.) Sie können keine Zugriffssynchronisation (vielleicht haben Sie fälschen kann so etwas wie es mit VBA automatisieren. Aber nach wie vor , wird dies nur dann ausgeführt werden, wenn die Datenbank geöffnet wird).

So wie ich empfehlen würde, ist zu SQL Server 2005/2008 auf den „zentrale“ Datenbank und verwenden Sie SQL Server Express Edition als Back-End auf „remote“ Datenbanken verwendet, dann verknüpften Tabellen in Access verwenden, um eine Verbindung zu diesen SSEE Datenbanken und Replikation, sie zu synchronisieren. Richten sie entweder Mergereplikation oder Snapshot-Replikation mit Ihrer „zentralen“ Datenbank als Herausgeber und Ihrer SSEE Datenbanken als Abonnent. Im Gegensatz zu Access Jet-Replikation können Sie die PK Nummerierung kontrollieren, aber für Sie, dies wird kein Problem sein, da Ihre Abonnent keine Änderungen drängen werden.

Neben der Skalierbarkeit, die SQL Server mit sich bringen würde, können Sie auch diese die Windows-Synchronization-Manager automatisieren (wenn Sie Ordner synchronisiert haben, das ist das lästige kleine Box, die erscheint und synchronisiert sie beim An- / Abmeldung), und es eingestellt so ein, dass es in einem bestimmten Intervall synchronisiert, beim Start, Herunterfahren oder bei einer Tageszeit und / oder wenn der Computer im Leerlauf ist, oder synchronisiert nur auf Anfrage. Auch wenn Access nicht für einen Monat läuft, kann seine Datenmenge jedes Mal der Benutzer mit dem Netzwerk verbinden aktualisiert werden. Sehr cool stuff.

Andere Tipps

Zugriffs Replikation kann umständlich sein, und wie Sie benötigen nur Anfragen mit einer gewissen Überprüfung anhängen, wäre es wahrscheinlich am besten sein, selbst etwas zu schreiben. Wenn die von jedem Laptop erfassten Daten nicht überlappen können, kann dies nicht allzu schwierig sein.

Sie müssen die Primärschlüssel berücksichtigen. Es kann sein, am besten den Benutzer oder Laptop Namen im Schlüssel zu übernehmen, um sicherzustellen, dass die Datensätze korrekt beziehen.

Die Antworten in diesem Thread mit Fehlinformationen über Jet-Replikation von Menschen gefüllt sind, die offensichtlich nicht daran gewöhnt haben und nur wiederholen, was sie gehört hat, oder sind zuschreiben Probleme zu Jet-Replikation, die tatsächlich Anwendung Designfehler widerspiegeln.

Es ist möglich, den Jet zu verwenden, Replikation in Access gebaut, aber ich warnt Sie, es ganz flockig ist.

Jet-Replikation ist nicht flockig. Es ist absolut zuverlässig, wenn sie richtig, genau wie jedes andere komplexe Werkzeug verwendet. Es ist wahr, dass bestimmte Dinge, die keine Probleme in einer nicht-replizierte Datenbank kann dazu führen, zu Problemen führen, wenn repliziert, aber das steht wegen der Natur das, was die Replikation von Vernunft jeder Datenbank-Engine zur Folge hat.

Es wird auch mess up Ihre PK auf was Tabellen Sie es tun auf, weil es nimmt zufällig unterzeichnet ganze Zahlen, um zu versuchen und vermeiden Schlüssel Kollisionen, so dass Sie vielleicht am Ende mit -1243482392912 als nächster PK auf einem bestimmten Datensatz. Das ist ein PITA eingeben, wenn Sie tun Art Nachschlag auf sie (wie ein Kunde ID, Auftragsnummer, usw.)

Surrogate Automatische Nummerierung PKs sollte nie an Benutzer in erster Linie ausgesetzt werden. Sie sind bedeutungslos Zahlen verwendet für Aufzeichnungen hinter den Kulissen verbinden, und wenn man sie für die Nutzer sind aussetzt ITIS ein Fehler in der Entwicklung Ihrer Anwendung.

Wenn Sie Sequenznummern tun müssen, werden Sie Ihre eigenen und befassen sich mit dem Thema rollen müssen, wie Kollisionen zwischen Repliken zu verhindern. Aber das ist ein Problem für die Replikation in jeder Datenbank-Engine. SQL Server bieten die Möglichkeit, Blöcke von Sequenznummern für einzelne Nachbauten auf der Datenbank-Engine Ebene Aufteilung und das ist ein wirklich nettes Feature, aber es kommt auf Kosten des erhöhten Verwaltungsaufwand von mehreren SQL Server-Instanzen beibehalten (mit allen Sicherheits- und Performance-Problemen daß sich bringt). In Jet-Replikation, dann würden Sie dies im Code zu tun haben, aber das ist kaum eine komplizierte Frage.

Eine andere Alternative wäre, eine Verbindung PK zu verwenden, wobei eine Spalte der Quellreplikat anzeigt.

Das ist aber nicht einige Fehler in der Replikation Implementierung von Jet -. Es ist ein Problem für jedes Replikationsszenario mit einem Bedarf für eine sinnvollen Sequenznummern

Sie können nicht Zugang automatisieren Synchronisation (vielleicht können Sie fälschen so etwas wie es von VBA. aber noch werden, dass nur dann ausgeführt werden, wenn die Datenbank wird geöffnet).

Das ist offenkundig unwahr. Wenn Sie den Jet Synchronizer installieren können Sie synchs (direkt, indirekt oder Internet synchs) planen. Auch ohne sie, könnten Sie eine VBScript planen regelmäßig und führen Sie die Synchronisation zu starten. Das sind nur zwei Methoden der automatisierten Jet synchroniziation erreichen, ohne dass Ihre Access-Anwendung zu öffnen.

Ein Zitat von MS-Dokumentation:

Verwenden Jet und Replikationsobjekte

JRO ist wirklich nicht der beste Weg, Jet-Replikation zu verwalten. Zum einen hat es nur eine Funktion darin, dass DAO selbst fehlt, das heißt, die Fähigkeit, eine indirekte synch in Code zu initiieren. Aber wenn du gehst, eine Abhängigkeit zu Ihren App hinzufügen (JRO erfordert einen Verweis, oder kann über die späte Bindung verwendet werden), dann konnte man auch eine Abhängigkeit von einer wirklich nützlichen Bibliothek hinzufügen für Jet-Replikation zu steuern, und das ist die TSI Synchronizer , erstellt von Michael Kaplan, einst der weltweit führende Experte auf Jet-Replikation (der seit auf Internationalisierung als seinen Bereich der Konzentration bewegt hat). Es gibt Ihnen die volle programmatische Steuerung fast alle Replikationsfunktionen, den Jet, einschließlich der Planung synchs aussetzt, alle Arten von Initiieren der Synchronisation und der dringend benötigten MoveReplica Befehl (der einzige legale Weg, um eine Replik ohne Replikation zu brechen zu verschieben oder zu umbenennen).

ist JRO einer der hässlichen Stiefkinder von Microsofts abgebrochener ADO-Überall-Kampagne. Sein Zweck ist, Jet-spezifische Funktionalität zu ergänzen, zu schaffen, was in ADO selbst unterstützt wird. Wenn Sie nicht mit ADO (und Sie sollen nicht mit einem Jet-Backend in einem Access-App sein), dann wollen Sie nicht wirklich JRO verwenden. Wie ich oben sagte, fügt es nur eine Funktion, die nicht bereits in DAO (das heißt, zur Einleitung einer indirekte Synch) ist. Ich kann nicht umhin zu denken, dass Microsoft wurde boshaft zu sein, indem eine eigenständige Bibliothek für Jet-spezifische Funktionalität erstellen und dann gezielt alle unglaublich nützlichen Funktionen auszulassen, die sie unterstützt haben konnte, hatte sie gewählt.

Nun, da ich der irrigen Behauptungen in den Antworten oben angebotenen angeordnet haben, hier ist meine Empfehlung:

Da Sie eine Append-only-Infrastruktur haben, tun, was @Remou empfohlen hat und etwas einrichten, um manuell die neuen Datensätze zu senden wohin sie gehen müssen. Und er ist richtig, dass Sie immer noch mit dem PK Problem zu tun haben, wie würden Sie, wenn Sie Jet-Replikation verwendet. Dies liegt daran, dass durch die Forderung notwendig ist neue Datensätze an mehreren Standorten hinzuzufügen, und ist für alle Replikation / Synchronisation Anwendungen üblich.

Aber eine Einschränkung: wenn das Add-only-Szenario in der Zukunft ändert, werden Sie abgespritzt und haben von Grunde auf neu starten oder eine ganze Menge haarigen Code schreiben Löschungen und Aktualisierungen zu verwalten (dies ist nicht einfach - Vertrauen ich, ich habe es getan!). Ein Vorteil von nur Jet-Replikation mit (auch wenn es am wertvollsten für Zwei-Wege-Synchronisationen, dh Änderungen an mehreren Standorten) ist, dass es das Add-nur Szenario ohne Probleme zu behandeln, und dann behandelt leicht voll Mergereplikation sollte es werden eine Anforderung in der Zukunft.

Zuletzt, ein guter Ort, um mit Jet-Replikation zu starten, ist die Jet Replication Wiki . Die Ressourcen, Best Practices und Dinge, die nicht glauben Seiten sind wahrscheinlich die besten Plätze zu starten.

Sie sollten lesen in Zugang Datenbank Replikation , da sich einige Informationen gibt.

Aber ich denke, damit sie mit Ihrer Anwendung korrekt arbeiten, werden Sie eine maßgeschneiderte Lösung ausrollen müssen die Methoden und Eigenschaften verfügbar diesen Zweck.

Verwenden Jet und Replication Objects (JRO), wenn Sie programmgesteuerte Kontrolle über den Austausch von Daten und Design-Informationen unter den Mitgliedern der Replikat-Gruppe in Microsoft Access-Datenbanken (MDB-Dateien) benötigen. Zum Beispiel können Sie JRO verwenden, um ein Verfahren zu schreiben, die automatisch einen Benutzers Replik mit dem Rest des Satzes synchronisiert, wenn der Benutzer die Datenbank öffnet. Um eine Datenbank programmatisch zu replizieren, muss die Datenbank geschlossen werden.

Wenn Sie Ihre Datenbank mit Microsoft Access 97 oder früher erstellt wurde, müssen Sie Data Access Objects (DAO) verwenden, um programm zu replizieren und synchronisieren.

Sie können mit DAO Methoden und Eigenschaften eine replizierte Datenbank in früheren Versionen von Microsoft Access erstellen und pflegen. Verwenden Sie DAO, wenn Sie benötigen programmgesteuerte Kontrolle über den Austausch von Daten und Design-Informationen unter den Mitgliedern der Replikat-Gruppe. Zum Beispiel können Sie DAO verwenden, um ein Verfahren zu schreiben, die automatisch einen Benutzers Replik mit dem Rest des Satzes synchronisiert, wenn der Benutzer die Datenbank öffnet.

Sie können die folgenden Methoden und Eigenschaften verwenden, um eine replizierte Datenbank zu erstellen und pflegen:


MakeReplica Methode

Synchronize Methode

ConflictTable Eigenschaft

DesignMasterID Eigenschaft

KeepLocal Eigenschaft

Replicable Eigenschaft

ReplicaID Eigenschaft

ReplicationConflictFunction Eigenschaft


Microsoft Jet bietet diese zusätzliche Methoden und Eigenschaften für die Erstellung und Pflege Teilreplikate (Replikate, das eine Teilmenge der Datensätze in einer vollständigen Nachbildung enthält):


ReplicaFilter Eigenschaft

PartialReplica Eigenschaft

PopulatePartial Methode

Sie sollten auf jeden Fall lesen das Synchronisieren von Daten Teil der Dokumentation .

verwenden ich die Replikation in a00 seit Jahren, bis a07 zu aktualisieren, bis gezwungen (wenn es ging). Das schwierigste Problem wir liefen in, auf betrieblicher Ebene wurde die Verwaltung des CONFLICTS . Wenn nicht rechtzeitig geschaffen, oder es gibt zu viele Benutzer frustriert und die Daten unzuverlässig werden.

Replikation funktionierte gut , wenn unsere Remote-Standorte nicht immer mit dem Internet verbunden waren. Damit konnten sie mit ihren Daten arbeiten, und synchronisieren, wenn sie könnten. Mindestens zweimal täglich.

Wir installieren eine separate Datenbank auf dem Remote-Computer, die die Synchronisation verwaltet werden, so dass nur der Benutzer ein Symbol auf dem Desktop klicken hatte die Synchronisation zu evozieren.

Der Benutzer hatte eine separate Taste, um Push / Pull-Feeds aus einer bestimmten FTP-Datei, die von den Legacy-Systemen aktualisieren würde.

Dieses Verfahren funktionierte recht gut, wie wir 30 dieser „Knoten“ hatte das Land arbeiten rund um ihre Daten und Aktualisierung auf den FTP-Servern zu verwalten.

Wenn Sie ernsthaft diesen Weg betrachten, lassen Sie mich wissen und ich kann Ihnen meine Dokumentation senden.

Sie können Ihre eigene Synchronisationssoftware schreiben, die an den Laptop angeschlossen wählt die diff davon db ist und fügt sie an den Master. Es ist abhängig von Ihrem Datenschema, wie einfach diese Operation sein wird. (Wenn Sie viele Tabellen mit FKs haben ... Sie müssen es intelligent tun). Ich denke, es wird die effizienteste sein, wenn Sie es selbst schreiben.

Die Automatisierung dieses Verhalten Replikation genannt wird, und Accesss Unterstützt , die anscheinend, aber ich habe es nie gesehen umgesetzt werden.

Als ich die meiste Zeit denke, der Laptop nicht mit dem Haupt DB verbunden ist, ist es keine gute Idee ist (zu Daten zu replizieren).

Wenn Sie ein 3rd-Party-Tool aussehen werden, es zu tun -. Für etwas, das das diff zwischen den Tischen vor dem Kopieren leicht tun kann, und es kann natürlich schrittweise von tun

FWIW:

automatische Nummerierung. Ich stimme mit David - sie sollten nie ausgesetzt werden. Um diese Versuchung zu entfernen, verwende ich eine Zufallsautowert.
Replikation. Früher habe ich dies ausführlich vor einigen Jahren, mit geplanten Synchronisierungen und GUIDs als PK verwenden. Ich fand immer wieder, dass all Schluckauf über das Netzwerk die Replikate beschädigt, mit dem Ergebnis, dass ich Daten retten musste und Neuausstellung Repliken. Schmerzhafte!

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow