Ich habe ein Problem in dem Moment, wo mehrere (gleiche Schema) Access 2003-Datenbanken auf Laptops verwendet werden.
Ich muss einen automatisierten Weg finden, um die Daten in eine zentrale Zugangsdatenbank zu synchronisieren.
Daten auf den Laptops werden nur an solche Aktualisierungs- / Löschvorgänge angehängt, was kein Problem darstellt.
Mit welchen Werkzeugen kann ich das leicht machen? Welche Faktoren beeinflussen die Entscheidung für das beste Werkzeug oder die beste Lösung?
Es ist möglich, die in Access integrierte Jet-Replikation zu verwenden, aber ich warne Sie, es ist ziemlich flockig. Es wird auch Ihre PK auf was auch immer Tabellen, die Sie es tun, da es zufällige signierte Ganzzahlen zu versuchen versucht und Schlüsselkollisionen zu vermasseln, so dass Sie am Ende mit -1243482392912 als Ihre nächste PK auf einem bestimmten Datensatz. Das ist ein PITA, den Sie eingeben müssen, wenn Sie irgendwelche Nachschlagevorgänge durchführen (wie eine Kundennummer, Bestellnummer usw.). Sie können die Zugriffssynchronisierung nicht automatisieren (vielleicht können Sie so etwas mit VBA fälschen, aber trotzdem , die nur ausgeführt wird, wenn die Datenbank geöffnet wird.)
Ich würde empfehlen, SQL Server 2005/2008 für Ihre "zentrale" Datenbank zu verwenden und SQL Server Express Edition als Back-End für Ihre "Remote" -Datenbanken zu verwenden und dann verknüpfte Tabellen in Access to zu verwenden Stellen Sie eine Verbindung zu diesen SSEE-Datenbanken und zur Replikation her, um sie zu synchronisieren. Richten Sie entweder Merge-Replikation oder Snapshot-Replikation
Neben der Skalierbarkeit, die der SQL-Server bietet, können Sie dies auch mit dem Windows Synchronization Manager automatisieren (wenn Sie Ordner synchronisiert haben, das ist die lästige kleine Box, die beim Anmelden / Abmelden angezeigt wird) nach oben, so dass es in einem bestimmten Intervall synchronisiert wird, beim Starten, Herunterfahren oder zu einer Tageszeit und / oder wenn der Computer im Leerlauf ist oder nur bei Bedarf synchronisiert wird. Auch wenn Access einen Monat lang nicht ausgeführt wird, kann der Datensatz jedes Mal aktualisiert werden, wenn Ihre Benutzer eine Verbindung mit dem Netzwerk herstellen. Sehr cooles Zeug.
Die Zugriffsreplikation kann umständlich sein, und da Sie nur anhängige Abfragen mit einer Überprüfung benötigen, wäre es wahrscheinlich am besten, wenn Sie selbst etwas schreiben. Wenn sich die von jedem Laptop gesammelten Daten nicht überschneiden können, ist dies möglicherweise nicht allzu schwierig.
Sie müssen die Primärschlüssel berücksichtigen. Es ist möglicherweise am besten, den Namen des Benutzers oder Laptops in den Schlüssel aufzunehmen, um sicherzustellen, dass sich die Datensätze korrekt verhalten.
Die Antworten in diesem Thread sind mit Fehlinformationen über Jet Replication von Leuten gefüllt, die sie offensichtlich nicht verwendet haben und nur Dinge wiederholen, die sie gehört haben, oder Jet Replication Probleme zuweisen, die tatsächlich Fehler beim Anwendungsdesign widerspiegeln.
Es ist möglich, den Jet zu benutzen Replikation in Access integriert, aber ich wird dich warnen, es ist ziemlich flockig.
Jet Replication ist nicht flockig. Es ist absolut zuverlässig, wenn es richtig verwendet wird, genau wie jedes andere komplexe Werkzeug. Es ist richtig, dass bestimmte Dinge, die in einer nicht replizierten Datenbank keine Probleme verursachen, zu Problemen führen können, wenn sie repliziert werden, aber das liegt an der Natur der Replikation durch beliebige Datenbank-Engine.
Es wird auch Ihre PK auf durcheinander bringen an welchen Tischen du es auch tust es wählt zufällig vorzeichenbehaftete ganze Zahlen aus, um es zu versuchen und vermeiden Sie Schlüsselkollisionen, so könnten Sie Am Ende mit -1243482392912 als Ihr nächste PK auf einem bestimmten Datensatz. Das ist ein PITA zum Eintippen wenn du welche machst Art von Nachschlagen darauf (wie ein Kunde ID, Bestellnummer usw.)
Surrogate Autonumber PKs sollten niemals Benutzern überhaupt zugänglich gemacht werden. Sie sind bedeutungslose Zahlen, die für das Verbinden von Datensätzen hinter den Kulissen verwendet werden, und wenn Sie sie Benutzern zeigen, ist dies ein Fehler in Ihrem Anwendungsdesign.
Wenn Sie Sequenznummern benötigen, müssen Sie Ihre eigenen rollen und sich damit auseinandersetzen, wie Sie Kollisionen zwischen Ihren Replikaten verhindern können. Aber das ist ein Problem für die Replikation in any -Datenbank-Engine. SQL Server bietet die Möglichkeit, Blöcke von Sequenznummern für einzelne Replikate auf Datenbank-Engine-Ebene zuzuordnen, und das ist ein wirklich nettes Feature, aber es geht zu Lasten eines erhöhten administrativen Aufwands durch die Verwaltung mehrerer SQL Server-Instanzen (mit allen Sicherheits- und Leistungsproblemen) das beinhaltet). In Jet Replication müssten Sie dies im Code tun, aber das ist kein kompliziertes Problem.
Eine andere Alternative wäre die Verwendung einer zusammengesetzten PK, wobei eine Spalte das Quellenreplikat angibt.
Aber das ist kein Fehler in der Replikationsimplementierung von Jet - es ist ein Problem für jedes Replikationsszenario, das sinnvolle Sequenznummern benötigt.
Sie können Access nicht automatisieren Synchronisierung (vielleicht können Sie vortäuschen etwas wie es mit VBA. aber Trotzdem wird das nur ausgeführt, wenn der Datenbank wird geöffnet).
Das ist offensichtlich unwahr. Wenn Sie den Jet-Synchronizer installieren, können Sie Synchronisierungen planen (direkte, indirekte oder Internet-Synchronisation). Auch ohne sie könnten Sie planen, dass ein VBScript periodisch ausgeführt wird und die Synchronisation durchführt. Dies sind nur zwei Methoden zur automatischen Jet-Synchronisierung, ohne dass Sie Ihre Access-Anwendung öffnen müssen.
Ein Zitat aus der MS-Dokumentation:
Verwenden Sie Jet- und Replikationsobjekte
JRO ist wirklich nicht der beste Weg, Jet Replication zu verwalten. Zum einen hat es nur eine Funktion, die DAO selbst fehlt, d. H. Die Fähigkeit, eine indirekte Synchronisation in Code zu initiieren. Wenn Sie jedoch eine Abhängigkeit zu Ihrer App hinzufügen (JRO benötigt eine Referenz oder kann über eine späte Bindung verwendet werden), können Sie genauso gut eine Abhängigkeit von einer wirklich nützlichen Bibliothek zur Steuerung der Jet-Replikation hinzufügen, und das ist TSI Synchronizer , erstellt von Michael Kaplan, einst der weltweit führende Experte für Jet-Replikation (wer hat seit auf Internationalisierung als sein Schwerpunktgebiet). Es bietet Ihnen volle programmatische Kontrolle fast aller Replikationsfunktionen, die Jet verfügbar macht, einschließlich der Planung von Synchronisierungen, Initiierung aller Arten von Synchronisation und des dringend benötigten MoveReplica-Befehls (der einzige legale Weg, ein Replikat zu verschieben oder umzubenennen, ohne die Replikation zu unterbrechen) / p>
JRO ist einer der hässlichen Stiefkinder von Microsoft's abgebrochener ADO-Everywhere-Kampagne. Sein Zweck besteht darin, Jet-spezifische Funktionen bereitzustellen, die die Unterstützung von ADO ergänzen. Wenn Sie ADO nicht verwenden (und Sie sollten nicht in einer Access-App mit einem Jet-Back-Ende sein), möchten Sie nicht wirklich JRO verwenden. Wie ich oben sagte, fügt es nur eine Funktion hinzu, die nicht bereits in DAO verfügbar ist (d. H. Eine indirekte Synchronisation initiieren). Ich kann nicht umhin zu denken, dass Microsoft boshaft war, indem ich eine eigenständige Bibliothek für die Jet-spezifische Funktionalität erstellte und dann absichtlich all die unglaublich nützlichen Funktionen ausblendete, die sie hätten unterstützen können, wenn sie gewählt hätten.
Nachdem ich die fehlerhaften Behauptungen in den obigen Antworten beseitigt habe, ist hier meine Empfehlung:
Da Sie nur eine Append-only-Infrastruktur haben, tun Sie, was @Remou empfohlen hat, und richten Sie etwas ein, um die neuen Datensätze manuell dorthin zu senden, wo sie hin müssen.Und er hat Recht, dass Sie sich immer noch mit dem PK-Problem befassen müssen, genauso wie Sie es mit Jet Replication tun würden. Dies ist erforderlich, weil neue Datensätze an mehreren Speicherorten hinzugefügt werden müssen und allen Replikations- / Synchronisierungsanwendungen gemeinsam sind.
Aber eine Einschränkung: Wenn sich das Add-Only-Szenario in Zukunft ändert, werden Sie abgespritzt und müssen von vorne anfangen oder eine ganze Menge haarigen Code schreiben, um Löschungen und Updates zu verwalten (das ist nicht einfach - Vertrauen ich, ich habe es getan!). Ein Vorteil der Verwendung von Jet Replication (auch wenn es für Zwei-Wege-Synchronisationen am wertvollsten ist, dh an mehreren Stellen bearbeitet wird) ist, dass das Add-Only-Szenario ohne Probleme gehandhabt wird und die vollständige Mergereplikation problemlos gehandhabt werden kann eine Anforderung in der Zukunft.
Ein guter Ausgangspunkt für Jet Replication ist das Jet Replication-Wiki . Die Seiten Ressourcen, Best Practices und Dinge, die man nicht glauben sollte, sind wahrscheinlich die besten Anlaufstellen.
Sie sollten in Access Datenbank Replikation , da gibt es einige Informationen da draußen.
Aber ich denke, damit Sie mit Ihrer Anwendung richtig arbeiten können, müssen Sie eine benutzerdefinierte Lösung mit dem Methoden und Eigenschaften verfügbar für dieses Ziel.
Verwenden Sie Jet- und Replikationsobjekte (JRO), wenn Sie eine programmatische Kontrolle über den Austausch von Daten- und Entwurfsinformationen zwischen Mitgliedern des Replikats in Microsoft Access-Datenbanken (nur MDB-Dateien) benötigen. Beispielsweise können Sie mit JRO eine Prozedur schreiben, die automatisch die Replik eines Benutzers mit dem Rest des Satzes synchronisiert, wenn der Benutzer die Datenbank öffnet. Um eine Datenbank programmatisch zu replizieren, muss die Datenbank geschlossen werden.
Wenn Ihre Datenbank mit Microsoft Access 97 oder früher erstellt wurde, müssen Sie Data Access Objects (DAO) verwenden, um sie programmatisch zu replizieren und zu synchronisieren.
Sie können eine replizierte Datenbank in früheren Versionen von Microsoft Access mithilfe von DAO-Methoden und -Eigenschaften erstellen und verwalten. Verwenden Sie DAO, wenn Sie eine programmatische Kontrolle über den Austausch von Daten und Entwurfsinformationen zwischen Mitgliedern des Replikatsatzes benötigen. Beispielsweise können Sie DAO verwenden, um eine Prozedur zu schreiben, die die Replik eines Benutzers automatisch 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 zu pflegen:
MakeReplicaMethodeSynchronizeMethodeConflictTableEigenschaftDesignMasterIDEigenschaftKeepLocalEigenschaftReplicableEigenschaftReplicaIDEigenschaftReplicationConflictFunctionEigenschaftMicrosoft Jet bietet diese zusätzlichen Methoden und Eigenschaften zum Erstellen und Verwalten von Teilreplikaten (Replikate, die eine Teilmenge der Datensätze in einer vollständigen Replik enthalten):
ReplicaFilterEigenschaftPartialReplicaEigenschaftPopulatePartialMethode
Sie sollten unbedingt den Synchronisierungsdaten Teil der Dokumentation lesen.
Ich habe die Replikation in a00 jahrelang verwendet, bis ich gezwungen wurde, auf a07 zu aktualisieren (als es wegging). Das problematischste Problem, auf das wir auf Unternehmensebene gestoßen sind, war die Verwaltung der CONFLICTS . Wenn sie nicht rechtzeitig verwaltet werden oder zu viele Benutzer sind, werden die Benutzer frustriert und die Daten werden unzuverlässig.
Die Replikation funktionierte gut , wenn unsere Remote-Sites nicht immer mit dem Internet verbunden waren. Dies ermöglichte ihnen, mit ihren Daten zu arbeiten und sie zu synchronisieren, wann immer sie konnten. Mindestens zweimal täglich.
Wir installieren eine separate Datenbank auf den Remotecomputern, die die Synchronisation verwaltet haben, so dass der Benutzer nur auf ein Symbol auf seinem Desktop klicken musste, um die Synchronisierung hervorzurufen.
Der Benutzer hatte eine separate Schaltfläche, um Feeds von einer bestimmten FTP-Datei, die von den Legacy-Systemen aktualisiert werden würde, zu übertragen.
Dieser Prozess funktionierte sehr gut, da 30 dieser "Knoten" im ganzen Land arbeiteten, ihre Daten verwalteten und auf die FTP-Server updaten.
Wenn Sie ernsthaft über diesen Weg nachdenken, lassen Sie es mich wissen und ich kann Ihnen meine Dokumentation schicken.
Sie können Ihre eigene Synchronisierungssoftware schreiben, die sich mit dem Laptop verbindet, wählt das Diff aus der Datenbank aus und fügt es in den Master ein. Es hängt von Ihrem Datenschema ab, wie einfach dieser Vorgang sein wird. (Wenn Sie viele Tabellen mit FKs haben, müssen Sie es intelligent machen). Ich denke, es wird am effizientesten sein, wenn Sie es selbst schreiben.
Diese Art von Verhalten zu automatisieren wird als Replikation bezeichnet, und unterstützt das anscheinend, aber ich habe es noch nie implementiert gesehen.
Da ich denke, die meiste Zeit ist der Laptop nicht mit der Haupt-DB verbunden, es ist sowieso keine gute Idee (um Daten zu replizieren).
Wenn Sie nach einem Tool von Drittanbietern suchen, um es zu tun - suchen Sie nach etwas, das den Unterschied zwischen den Tabellen vor dem Kopieren leicht machen kann, und natürlich schrittweise tun kann.
FWIW:
Tags und Links ms-access data-synchronization