Mai 21, 2022, 03:49:36

Neuigkeiten:

Ist euer Problem gelöst, dann bitte den Knopf "Thema gelöst" drücken!


ACCESS DB (accdb) mit SQL Server synchronisieren

Begonnen von Martin H., März 22, 2022, 16:00:23

⏪ vorheriges - nächstes ⏩

Martin H.

Hallo zusammen,

für ein Projekt habe ich nach wie vor Access 2010 im Einsatz, weil das die letzte Version ist, in der ich via VBA noch auf die eingebauten Replikationsfeatures zugreifen kann.
Nun soll das ganze Projekt aber auf eine neuere Accessversion umgestellt werden, weil es immer häufiger zu Problemen in Zusammenhang mit der Office 365-Installation und parallel installierten ACCESS 2010 RTE kommt.
Zudem ist die Replikation von ACCESS Frontends (Clients) zum Backend (Designmaster) auch nicht sonderlich perfomant über die Internetleitung und macht zuweilen auch noch andere Probleme.

Allerdings gibt es zwei Anforderungen, die ich nicht ändern kann:
  • Clients müssen offline arbeiten können, d.h. Replikation mit beidseitiger Synchronisation ist zwingend erforderlich
  • Eine Umstellung der Frontend-Logik in Bezug auf Abfragen und VBA auf TSQL ist nicht möglich. Die Anwendung ist funktional so umfangreich, dass ich damit vermutlich 6-12 Monate beschäftigt wäre. Das wäre zwar auch eine schöne Absicherung, aber der Kunde kann sich das wohl nicht leisten ;-)

Nun habe ich zwei Ansätze, aber keine Erfahrung dazu. Mit SQL Server und TSQL kenne ich mich ein bisserl aus, bin aber lang kein Experte. Mit Replikation habe ich bisher noch nichts gemacht.

1. Idee:
Der Server (Backend) erhält eine SQL Server Instanz (Express wenn möglich) und alle Datenbanken/Tabellen werden entsprechend migriert. Alle Clients erhalten eine lokale SQL Server Express Installation.
Die lokale SQL Instanzen auf den Clients synchronisieren via SQL Server Replikation per Pull-Request mit dem Server ("Designmaster"). Ebenfalls befindet sich die ACCESS-Anwendung auf den Clients. In ACCESS binde ich die lokalen SQL Server Express Tabellen dann per ODBC ein und spare mir die Anpassung der Abfragen und größten Teil des Codes. Die Perfomance dürfte darunter nicht leiden, da der Client alleine und nur lokal via ODBC auf die Tabellen zugreift.

Hier meine Fragen dazu:
  • Ist das so überhaupt realistisch?
  • Benötige ich für den "Designmaster" eine SQL Server Lizenz oder geht das auch mit Express?
  • Benötigt der Client für Pull-Requests eine Lizenz oder geht das auch mit Express?

2. Idee:
Das wäre gewissermaßen die Alternative, falls 1. völlig unrealistisch ist (Kosten/Umsetzbarkeit). Hier würde ich ebenfalls eine SQL Server Express Instanz auf einem Datenbankserver als "Designmaster" installieren, sowie die Backendtabellen aus ACCESS migrieren. Bei den ACCESS-Clients wird aber keine SQL Server Version installiert. Es werden die Backend-Tabellen, sofern der Server erreichbar ist, im ACCESS-Frontend direkt per ODBC eingebunden. Zusätzlich verbleibt aber von jeder Tabelle eine lokale Kopie im  ACCESS-Frontend. Also quasi als hätte man eine klassisches pre ACCESS 2010 Designmaster / Replikat Struktur und würde die Tabellen vom Designmaster zusätzlich lokal verknüpfen.
Den Abgleich der Daten würde ich dann via Abfragen und Code beim öffnen der Anwendung bzw. auf Knopfdruck steuern. Eine einfache Synchronisation in beide Richtung ist nicht sonderlich kompliziert, wenn ich auf die Feldgesteuerte Synchronisation verzichte und Zeitstempel im DM und Client nur auf Datensatzebene vergleiche. Last Change wins und gut ist. Da ist das Projekt zum Glück nicht sonderlich anspruchsvoll, da selten der gleiche Datensatz bearbeitet wird und wenn eben der letzte Bearbeiter auch das letzte Wort hat. Nur ist diese Lösung halt schon wieder relativ aufwändig in der Umsetzung (Kosten für den Kunden), weshalb ich 1. bevorzugen würde.

Ich habe die letzten Stunden damit verbracht zum Thema "SQL Server mit ACCESS replizieren" zu recherchieren, habe dazu aber wenig hilfreiches gefunden. Über SQL Server Replikation im Allgemeinen gibts da schon wesentlich mehr, aber das ist mir etwas zu viel für den Moment, ich weiß nicht recht wo ich anfangen soll und möchte vermeiden dass ich mich in der falschen Richtung verlaufe.

Hat hier jemand schon Erfahrungen gesammelt mit einer vergleichbaren Anforderung?
Für jegliche Ideen oder Anregungen wäre ich dankbar.

Lieben Gruß
Martin

ebs17

Tutorial: Vorbereiten von SQL Server auf die Replikation (Verleger, Verteiler und Abonnent)
ZitatVoraussetzungen

Dieses Tutorial richtet sich an Benutzer, die zwar mit grundlegenden Datenbankvorgängen vertraut sind, aber nur über begrenzte Erfahrungen in Bezug auf die Replikation verfügen.

Für dieses Tutorial benötigen Sie SQL Server, SQL Server Management Studio (SSMS) und eine AdventureWorks-Datenbank:

    Installieren Sie auf dem Verlegerserver (Quelle) Folgendes:
        Eine beliebige Edition von SQL Server, mit Ausnahme von SQL Server Express oder SQL Server Compact. Diese Editionen können nicht als Verleger für Replikationen verwendet werden.

ZitatReplikation von ACCESS Frontends
... ist ziemlicher Unsinn. Ein FE würde man schlicht austauschen. Mit DATEN-Replikation ist die Aufgabe groß genug.

Ich selber habe vor 20 Jahren mit Replikation in Access gespielt, diese aber als unbefriedigend empfunden und beseite gelegt.
Mit freundlichem Glück Auf!

Eberhard

Martin H.

Hallo Eberhard,

Danke für Deine Kommentare.

Zitat von: ebs17 am März 23, 2022, 08:38:21Tutorial: Vorbereiten von SQL Server auf die Replikation (Verleger, Verteiler und Abonnent)

Ok, es benötigt also eine kostenpflichtige Version von SQL Server auf dem Server.
Ob man mit einer SQL Server Express Installation einen Pull Request ausführen kann ist mir leider trotzdem nicht so klar.

ZitatReplikation von ACCESS Frontends
... ist ziemlicher Unsinn. Ein FE würde man schlicht austauschen. Mit DATEN-Replikation ist die Aufgabe groß genug.

Ich selber habe vor 20 Jahren mit Replikation in Access gespielt, diese aber als unbefriedigend empfunden und beseite gelegt.

Ich habe es nicht klar genug skiziert, sorry. Auf den Clients sind Anwendung und Datenbank natürlich voneinander getrennt (Hier eine detailierte Beschreibung des Aufbaus: https://tgasoft-doku.ibdm.de/grundlagen/aufbau-struktur.html). Anwendungen werden bei einem Update einfach ausgetauscht. Die Replikationslogik würde natürlich nicht in der Anwendung, sondern in den Datenbankdateien mit den Tabellen ausgeführt werden. So eine Replikationslogik umzusetzen halte ich im Prinzip aber trotzdem für nicht sehr schwer, wenn man sich auf die Prüfung von Datensatzänderungen beschränkt und nicht auf einzelne Felder konzentriert. Dafür braucht es im Prinzip nur einen Zeitstempel in der Tabelle des Designmasters und in der Tabelle des Clients, welche das Datum der letzten Datensatzänderung protokolliert, sowie einen gemeinsamen Primärschlüssel. Der jüngste Datensatz gewinnt immer und wird über VBA oder Abfragen in die eine oder andere Richtung geschrieben. Nur ist es halt sehr aufwändig, da es sich um sehr viele Tabellen handelt. Und es hat einen großen Nachteil wenn es Änderungen an der Tabellenstruktur gibt, diese müsste man mit einer eigenen Updatelogik auf die Clients schieben (z.B. via Update der Anwendung die dann beim starten prüft ob die erwarteten Felder und Tabellen vorhanden sind und entsprechend ergänzt).

Grundsätzlich wäre mir Variante 1 aber lieber. Was mich noch abhält sind:
1. Lizenzkosten für SQL Server
2. Ungewissheit ob der PULL Request auch von einem SQL Server Express Client gestartet werden kann
3. Unsicherheit ob ich damit das gewünschte Ergebnis erzielen kann (jemand der hier schon Erfahrung gesammelt hat, könnte mir hier mehr Gewissheit geben denke ich)

LG
Martin

markus888

Zitat von: Martin H. am März 23, 2022, 10:17:49Ob man mit einer SQL Server Express Installation einen Pull Request ausführen kann ist mir leider trotzdem nicht so klar.

Möglichkeiten gibt es viele.
Du solltest aber eine konkrete Frage stellen, dann müsste man nicht raten was du meinst.
10 Jahre Access

Martin H.

ZitatMöglichkeiten gibt es viele.
Du solltest aber eine konkrete Frage stellen, dann müsste man nicht raten was du meinst.

Entschuldige, aufgrund der mangelnden Erfahrung mit Replikation unter SQL Server (bzw. Funktionen in SQL Server > Express) weiß ich nicht so genau wie und was ich fragen soll. Zum Hintergrund meiner Frage: Ich habe gelesen, dass es prinzipiell die Möglichkeit gibt einen Abonennten per Pull oder Push zu synchronisieren. Bei Pull initiert der Client die Synchronisation mit dem Server. Da für automatisierungen so wie ich das verstanden habe immer der SQL Server Agent notwendig ist, der ja in SQL Server Express nicht zur Verfügung steht, hatte ich mich gefragt ob ich mit SQL Server Express überhaupt automatisiert einen Pull starten kann.

markus888

Zitat von: Martin H. am März 23, 2022, 17:14:32Da für automatisierungen so wie ich das verstanden habe immer der SQL Server Agent notwendig ist

Zuerst sagtest du es soll per Knopfdruck funktionieren, jetzt wieder automatisch.
Du musst dich schon entscheiden.

Persönlich habe ich mit Wartung nichts zu tun, das macht die IT.

Wenn es um Wartung rund um den SQL Server geht, würde ich da eher ein SQL Server Forum aufsuchen.
10 Jahre Access

Martin H.

Zitat von: markus888 am März 23, 2022, 21:36:52Zuerst sagtest du es soll per Knopfdruck funktionieren, jetzt wieder automatisch.
Du musst dich schon entscheiden.

Habe ich nicht. Ich habe von einer 1. Idee gesprochen: Datenbankserver mit SQL Server und Client mit SQL Server Express der einen Pull Request ausführt. Über das Wie des Pull Requests habe ich noch nicht gesprochen.
Und dazu habe ich drei konkrete Fragen gestellt:
1. Ist das so überhaupt realistisch?
2. Benötige ich für den "Designmaster" eine SQL Server Lizenz oder geht das auch mit Express?
3. Benötigt der Client für Pull-Requests eine Lizenz oder geht das auch mit Express?

Danach aber ich von einer 2. Idee geredet, falls die 1. Idee nicht funktioniert, z.B. wenn ich für einen Client mit SQL Server Express einen SQL Server Agent bräuchte, was mit Express nicht geht. Das weiß ich aber nicht, und ist für mich alles etwas undurchsichtig momentan, deshalb habe ich dieses Forum aufgesucht.

In der 2. Idee habe ich dann ein ganz anderes Szenario gezeichnet und von einem Knopfdruck gesprochen.

Aber lasst es gut sein, ich hatte mich an den Austausch in den damaligen Google Groups erinnert und war davon ausgegangen dies sei hier in einer ähnlich positiven Form möglich. Anscheinend ist dem nicht so. Thema kann geschlossen werden. Danke für eure Anteilnahme.

Grüße
Martin