Replikation selbst programmieren?

[Klaus B.]

Hallo!
Ich arbeite seit Jahren mit replizierten Access-Datenbanken. Da die Datenbanken auch offline zur Verfügung stehen müssen, bin ich damit gut gefahren - nutze aber entsprechend immer noch Access 2010.
Mit dem kommenden Umstieg auf Win 11 fürchte ich um die Aktivierbarkeit von Office 2010  auf dann neuen Rechnern und suche eine Alternative.
Am einfachsten scheint mir, die Replikationsfunktion selbst zu programmieren.
Hat jemand damit Erfahrungen?
Was wären sinnvolle Alternativen?
Vielen Dank! 

[PhilS]

Mit dem kommenden Umstieg auf Win 11 fürchte ich um die Aktivierbarkeit von Office 2010  auf dann neuen Rechnern und suche eine Alternative.

Hier wäre es doch sinnvoll, das auszuprobieren anstatt zu spekulieren bzw. zu fürchten.
Eine Windows 11 VM zu Evaluierungszwecken kannst du dir einfach runterladen. Dann A2010 zu installieren und deine Anwendung zu testen, sollte dir in recht kurzer Zeit Ergebnisse liefern.

[ebs17]

Replikation (= gegenseitiges Synchronisieren) - einfach - funktionierend:
Meine eigenen Tests damit unter eigenen Anforderungen waren da unbefriedigend, die man mit Eigenprogrammierung auch nicht befriedigend lösen kann.

Es gibt zwei Grundprobleme:

1) Wenn zwei User zwischen zwei Synchronisierungsabläufen den gleichen Feldwert in einer Tabelle ändern, entsteht der Konflikt, dass entschieden werden muss, welcher der beiden Werte nun beibehalten werden soll und welcher in die Tonne geht.
Bei Replikation geht es um massenhafte solcher Fälle, die automatisiert entschieden werden müssen. Wenn nicht einer Seite grundsätzlich recht gegeben wird, ist ein wahlweises Entscheiden problematisch, zudem ist hier ein Stück Subjektivität enthalten, und der User in der Zentrale, der die Synchronisierung ausführen würde, ist vielleicht nicht der bestgeeignete Entscheider.

2) Wenn zwei User einen neuen Wert als neuen Datensatz anlegen, wird dieser unter unterschiedlichen ID's abgelegt, bei GUID sowieso, bei Autowert sehr wahrscheinlich. Hier gibt es also eine Störung der Datenintegrität. Bei einer Tabelle ist das noch leicht reparabel. Ist das hier aber eine Primärtabelle, wo der Primärschlüssel als Fremdschlüssel in weitere Tabellen geht, die ihrerseits in abhängigen Tabellen Datensätze mit eigenen Schlüsseln erzeugen (=> Tiefenschachtelung im Datenmodell), dann ist das alles nichttrivial und die Wiederherstellung der Datenintegrität nicht per Handschlag lösbar.

Unter dem Strich muss man also die eigene Arbeitsweise analysieren. Wenn jeder User überall alles machen kann, dann hat man mit der Replikation ein erhebliches verbleibendes Problem. Wenn User an jeweils eigenen Themen arbeiten und es dabei keine schreibenden Datenüberschneidungen gibt (und das sichergestellt ist), dann ist ein Zusammenführen der Daten nicht so ein Problem und kann durchaus auch per Eigenprogrammierung umgesetzt werden - pro Tabelle und User eine Anfüge- und eine Aktualisierungsabfrage. Löschen von Datensätzen lässt man an der Stelle besser sein.

Wer es mit Massendatenverarbeitung nicht so hat, kann auch ein AuditTrail einführen und dann gespeicherte Änderungen einzeln zusammenbringen. Das wird zeitaufwändig sein, aber Schleifen mit Einzelschritten verstehen viele einfacher.

Selbst programmieren: Da man sich auf komplexe inhaltliche Anforderungen einlassen muss, sollte man sein Handwerk (SQL, VBA) recht gut beherrschen. Das ist definitiv keine Spielwiese für blauäugiges Lerning by doing.

[Klaus B.]

Mit dem kommenden Umstieg auf Win 11 fürchte ich um die Aktivierbarkeit von Office 2010  auf dann neuen Rechnern und suche eine Alternative.

Hier wäre es doch sinnvoll, das auszuprobieren anstatt zu spekulieren bzw. zu fürchten.
Eine Windows 11 VM zu Evaluierungszwecken kannst du dir einfach runterladen. Dann A2010 zu installieren und deine Anwendung zu testen, sollte dir in recht kurzer Zeit Ergebnisse liefern.

Super Tipp; Dankeschön!

[PhilS]

Bei Replikation geht es um massenhafte solcher Fälle, die automatisiert entschieden werden müssen. Wenn nicht einer Seite grundsätzlich recht gegeben wird, ist ein wahlweises Entscheiden problematisch, zudem ist hier ein Stück Subjektivität enthalten, und der User in der Zentrale, der die Synchronisierung ausführen würde, ist vielleicht nicht der bestgeeignete Entscheider.

Das ist ein zentrales Problem. Eine automatisierte Entscheidung ist bei Replikationskonflikten eben meist nicht (sinnvoll) möglich. 
D.h. man muss einem qualifizierten Benutzer eine geeignete GUI bereitstellen um den Sachverhalt eines Konfliktes vollständig zu verstehen und dann, mit geeigneten Tools, eine sinnvolle Entscheidung darüber zu treffen. - Das wird schnell sehr komplex, weil eine rein generische GUI für alle Tabellen oft den Hintergrund und die Implikationen einer Konfliktlösung nicht ausreichend verständlich darstellen.

[Klaus B.]

Herzlichen Dank!

Beide Probleme sind mir prinzipiell bekannt, aber im Rahmen unserer Datenbankanwendungen gut beherrschbar. Ich habe einen kleinen eigenen Konfiktmanager programmiert, um dieses Probleme dann fallweise lösen zu können, und auch das Anlegen neuer Datensätze durch verschiedene Nutzer ist so gelöst, dass es praktisch nicht vorkommt. Dass zwei Nutzer den gleichen Datensatz bearbeiten passiert durchaus, ist aber über den Konfliktmanager dann im Einzelfall problemlos lösbar.

Anfüge- und Aktualisierungsabfragen scheinen mir nicht die Funktionalität zu haben, die ich brauche; auch das Löschen von Datensätzen sollte beispielsweise weitergegeben werden.

Gibt es Erfahrungen damit, die Replikationsfunktion in einer neueren Access-Datenbank selbst zu programmieren? Worauf müsste man bei der Tabellenerstellung achten? Hat das jemand schon einmal gemacht - oder wo könnte ich Hinweise finden?

Replikation (= gegenseitiges Synchronisieren) - einfach - funktionierend:
Meine eigenen Tests damit unter eigenen Anforderungen waren da unbefriedigend, die man mit Eigenprogrammierung auch nicht befriedigend lösen kann.

Es gibt zwei Grundprobleme:

1) Wenn zwei User zwischen zwei Synchronisierungsabläufen den gleichen Feldwert in einer Tabelle ändern, entsteht der Konflikt, dass entschieden werden muss, welcher der beiden Werte nun beibehalten werden soll und welcher in die Tonne geht.
Bei Replikation geht es um massenhafte solcher Fälle, die automatisiert entschieden werden müssen. Wenn nicht einer Seite grundsätzlich recht gegeben wird, ist ein wahlweises Entscheiden problematisch, zudem ist hier ein Stück Subjektivität enthalten, und der User in der Zentrale, der die Synchronisierung ausführen würde, ist vielleicht nicht der bestgeeignete Entscheider.

2) Wenn zwei User einen neuen Wert als neuen Datensatz anlegen, wird dieser unter unterschiedlichen ID's abgelegt, bei GUID sowieso, bei Autowert sehr wahrscheinlich. Hier gibt es also eine Störung der Datenintegrität. Bei einer Tabelle ist das noch leicht reparabel. Ist das hier aber eine Primärtabelle, wo der Primärschlüssel als Fremdschlüssel in weitere Tabellen geht, die ihrerseits in abhängigen Tabellen Datensätze mit eigenen Schlüsseln erzeugen (=> Tiefenschachtelung im Datenmodell), dann ist das alles nichttrivial und die Wiederherstellung der Datenintegrität nicht per Handschlag lösbar.

Unter dem Strich muss man also die eigene Arbeitsweise analysieren. Wenn jeder User überall alles machen kann, dann hat man mit der Replikation ein erhebliches verbleibendes Problem. Wenn User an jeweils eigenen Themen arbeiten und es dabei keine schreibenden Datenüberschneidungen gibt (und das sichergestellt ist), dann ist ein Zusammenführen der Daten nicht so ein Problem und kann durchaus auch per Eigenprogrammierung umgesetzt werden - pro Tabelle und User eine Anfüge- und eine Aktualisierungsabfrage. Löschen von Datensätzen lässt man an der Stelle besser sein.

Wer es mit Massendatenverarbeitung nicht so hat, kann auch ein AuditTrail einführen und dann gespeicherte Änderungen einzeln zusammenbringen. Das wird zeitaufwändig sein, aber Schleifen mit Einzelschritten verstehen viele einfacher.

Selbst programmieren: Da man sich auf komplexe inhaltliche Anforderungen einlassen muss, sollte man sein Handwerk (SQL, VBA) recht gut beherrschen. Das ist definitiv keine Spielwiese für blauäugiges Lerning by doing.

[Klaus B.]

Genau! Das habe ich entsprechend programmiert und der qualifizierte Nutzer bin ich dann selbst.

Das funktioniert, wie gesagt, alles prima, trotz dieser Schwierigkeiten. Und ich würde das für eine Accessdatenbank nach 2010 gerne selbst impementieren ...

Bei Replikation geht es um massenhafte solcher Fälle, die automatisiert entschieden werden müssen. Wenn nicht einer Seite grundsätzlich recht gegeben wird, ist ein wahlweises Entscheiden problematisch, zudem ist hier ein Stück Subjektivität enthalten, und der User in der Zentrale, der die Synchronisierung ausführen würde, ist vielleicht nicht der bestgeeignete Entscheider.

Das ist ein zentrales Problem. Eine automatisierte Entscheidung ist bei Replikationskonflikten eben meist nicht (sinnvoll) möglich.
D.h. man muss einem qualifizierten Benutzer eine geeignete GUI bereitstellen um den Sachverhalt eines Konfliktes vollständig zu verstehen und dann, mit geeigneten Tools, eine sinnvolle Entscheidung darüber zu treffen. - Das wird schnell sehr komplex, weil eine rein generische GUI für alle Tabellen oft den Hintergrund und die Implikationen einer Konfliktlösung nicht ausreichend verständlich darstellen.

[ebs17]

Erfahrungen? Nachdem ich Anfang der 2000er die Access-implementierte Replikation als nicht ausreichend empfand für ein Datenmodell mit 30 Tabellen, habe ich mich mit einer eigenen  Lösung halbwegs erfolgreich beschäftigt - bei einem Finanzdienstleister mit etwa 12 Teilnehmern hat das weitgehend funktioniert, allerdings mit einigen ordnungstechnischen Auflagen an die User, um die genannten Probleme zu entschärfen. Auflagen werden aber nicht immer und nicht immer konsequent eingehalten.

auch das Löschen von Datensätzen sollte beispielsweise weitergegeben werden

Gelöscht heißt Information verloren. dann müsste man sich vor dem Löschen den datensatz oder zumindest die ID in einer zusätzlichen Tabelle dokumentieren.

In jedem Falle sollte man in den Tabellen Zeitstempel für Neuanlage + Änderung mitführen, um für die Synchronisation nur neue Datensätze seit dem letzten Abgleich berücksichtigen zu müssen, das macht um so mehr Sinn, je größer die Tabellen sind.
Bei einem Abgleich sollte einem dann auch das Wirken der referentiellen Integrität nicht unbekannt sein.

Code [Auswählen] Erweitern

Anfüge- und Aktualisierungsabfragen scheinen mir nicht die Funktionalität zu habenDas verstehe ich nicht. Bei Tabellen über einen Zehnzeiler hinaus ist für mich Massendatenverarbeitung obligatorisch, wenn einsetzbar.

[Klaus B.]

Code [Auswählen] Erweitern

Anfüge- und Aktualisierungsabfragen scheinen mir nicht die Funktionalität zu habenDas verstehe ich nicht. Bei Tabellen über einen Zehnzeiler hinaus ist für mich Massendatenverarbeitung obligatorisch, wenn einsetzbar.

Was ich meinte ist, dass mir nicht klar ist, wie mir diese Abfragen das bei der Synchronisierung von zwei unabhängigen  Datenbanken helfen können ... ?
 

[Klaus B.]

Vielleicht als Ergänzung:

Ich finde immer wieder den Hinweis auf SQL Server. Ist es damit möglich, eigenständige Datenbanken (die also auch offline funktionieren) zu synchronisieren?

Vielen Dank!

[ebs17]

Synchronisierung von zwei unabhängigen  Datenbanken

Beschränken wir da die Betrachtung auf jeweils eine Tabelle: Da trage ich in die eine Tabelle ein, was es in der anderen neu gibt. Gespeichert wird immer datensatzweise. Also kann ich bei unkritischen Verhältnissen alles auf einmal übertragen statt Werte einzeln zu schieben. Dies aus stilistischen und Performancegründen, und als Datenbänkler bevorzuge ich da Abfragen (SQL).

Zu SQL Server habe ich keine Erfahrungen. Die genannten Grundprobleme sind aber die gleichen. In Foren sieht man praktisch keine Diskussion zu Replikation, was auf eine sehr geringe bis ausbleibende Verwendung hindeutet.

Allgemein wird immer ein zentrales Backend empfohlen, auf das die Clients live zugreifen, und mit heutigem meist verfügbaren Internet lässt sich dieser Ansatz besser umsetzen als vor zwei Jahrzehnten.

[Klaus B.]

Synchronisierung von zwei unabhängigen  Datenbanken

Beschränken wir da die Betrachtung auf jeweils eine Tabelle: Da trage ich in die eine Tabelle ein, was es in der anderen neu gibt. Gespeichert wird immer datensatzweise. Also kann ich bei unkritischen Verhältnissen alles auf einmal übertragen statt Werte einzeln zu schieben. Dies aus stilistischen und Performancegründen, und als Datenbänkler bevorzuge ich da Abfragen (SQL).

Zu SQL Server habe ich keine Erfahrungen. Die genannten Grundprobleme sind aber die gleichen. In Foren sieht man praktisch keine Diskussion zu Replikation, was auf eine sehr geringe bis ausbleibende Verwendung hindeutet.

Allgemein wird immer ein zentrales Backend empfohlen, auf das die Clients live zugreifen, und mit heutigem meist verfügbaren Internet lässt sich dieser Ansatz besser umsetzen als vor zwei Jahrzehnten.

Vielen Dank! Dass es dazu so gut wie nichts gibt ist mir auch schon aufgefallen ...
Das mit den Abfragen so zu nutzen ist eine gute Anregung, falls ich sonst nicht weiterkomme.
Noch eine Frage zum Backend: Gibt es eine gute Lösung für eine Backend im Netz? Im Heimnetz ist das ja kein Problem; damit, dass über das Internet zu machen, habe ich noch keine Erfahrung.

[Josef P.]

Hallo!

Gibt es eine gute Lösung für eine Backend im Netz?

Dafür kommt meiner Meinung nach nur noch ein aktives DBMS in Frage.
SQL-Server kannst du z. B. über Microsoft Azure nutzen. Du bist da aber nicht auf MS-SQL-Server beschränkt. PostgreSQL, MySQL (und Clone) können ebenso verwendet werden.
Vielleicht ist auch ein aktives DBMS im Firmennetzwerk mit VPN-Zugang eine brauchbare Variante.


zu Replication mit SQL-Server:
https://learn.microsoft.com/en-us/sql/relational-databases/replication/sql-server-replication
Anm.: Erfahrung habe ich keine damit.


Gruß
Josef

[ebs17]

Da die Datenbanken auch offline zur Verfügung stehen müssen

Die erste Frage wäre, welche Verbindung Du nun zwischen den Datenbanken herstellen kannst. Access ist bei Internet- und WLAN-Verbindungen empfindlich bei Verbindungsstörungen - gefahr des Absturzes, Datenstörungen.

Eine Möglichkeit wäre auch ein Terminalserver, auf dem Backend sowie die Frontends der Clients laufen. Zum User würden dann nur Bildschirminhalte geschickt, er selber würde über die Oberfläche Befehle an das Client-FE schicken, so dass ein Datenverkehr recht gering ist und Unterbrechungen keine Datenfehler verursachen. Kostet halt einigen Aufwand und Geld (könnte auch durch Drittanbieter gehostet werden).

das Anlegen neuer Datensätze durch verschiedene Nutzer ist so gelöst, dass es praktisch nicht vorkommt. Dass zwei Nutzer den gleichen Datensatz bearbeiten passiert durchaus, ist aber über den Konfliktmanager dann im Einzelfall problemlos lösbar

Das ist für sich recht übersichtlich umsetzbar, da braucht man keine Replikation als solche.

1. Vereinbarung: Neue Datensätze legt nur genau ein bestimmter User an. Dann entfällt das genannte ID-Problem.

2. Vereinbarung: Jede relevante Tabelle bekommt ein Date-Feld, wo der Zeitpunkt der Datensatzänderung bzw. -neuanlage abgelegt wird. Das könnte man über ein DataMacro lösen, um neben Änderungen über Formular auch alle anderen Möglichkeiten (Aktionsabfrage, Recordsetaktion, Import, Handbetrieb) abzudecken.
Der Abgleich betrifft also nur Änderungen in BESTEHENDEN Datensätzen, wo Inhalte geändert oder ergänzt werden.

- P1: Man merkt sich in einer zusätzlichen Tabelle den Zeitpunkt eines Abgleiches.
- P2: Nun kann man einfach ermitteln, welche Datensätze sich seit diesem letzten Zeitpunkt geändert haben. Nur diese bezieht man in die folgende Verarbeitung ein.
- P3: Jetzt kann man pro Tabellenpaarung zwei Aktualisierungsabfragen laufen lassen für jene Datensätze, wo der Timestamp der Quell-DB größer als der gemerkte Zeitpunkt ist und der Timestamp der Ziel-DB kleiner als der gemerkte Zeitpunkt ist.
- P4: Die Datensätze, wo der Timestamp in beiden Tabellen größer als der gemerkte Zeitpunkt ist, führst Du dem individuellen Konkliktmanager vor.

Eine solche Synchronisierung könnte man auch derart abändern, dass man nur ein Backend aktualisiert und dem Zweituser dann einfach dieses Backend als Kopie zurückgibt.

[Wolfi59]

Guten Abend in die Runde, schon lange nicht mehr dagewesen :-) Ich hatte auch Replikate in Anwendung und nach dem Wegfall der Replikationsmodule selbst versucht eine Lösung zu finden.
Am besten hat das noch funktioniert, als Acc 2003 im Einsatz war.
Die DB's sind mittlerweile alle durch die Versionen 365-21 ersetzt worden. Der Grund waren die Sicherheitsvorgaben der einzelnen Unternehmen als auch das Verlangen nach dem Einsatz einheitlicher Office-Software.
Das große Problem waren die vielen Laptops, die im Außendienst zeitgleich tätig waren und somit viele Konflikte aufgetreten sind, die in der Summe eigentlich nie ganz fehlerfrei aufgelöst werden konnten.
Vielleicht mal so als Anregung:
Die Replikation wurde wegen der wirklich großen Probleme durch direkte Zugriffe über eine gesicherte VPN Verbindung abgelöst.
Die Lösung über VPN klappt zwar recht gut, aber eben nur unter der Voraussetzung das eine gute Netzabdeckung am Einsatzort vorhanden ist.
Ich fand es wirklich sehr schade, dass die accesseigene Replikation fallen gelassen, und keine Ersatzlösung bereitgestellt wurde. Für DB-Entwickler die Anwendungen für Außendienstler entwickeln müssen ein totaler Rückschritt.