6
ACCESS Dateien synchronisieren
Hallo Allerseits,
zwei Rechner, zwei *mdb-Dateien.
Diese sollen am Ende eines Tages synchronisiert werden, damit beide Benutzer stets ueber die gleichen Datensaetze verfuegen.
Dummerweise handelt es sich um eine VB-Applikation die auf MS ACCESS 97 basiert, auf den Rechnern arbeitet jedoch ACCESS 2003. Daher bin ich ein wenig zurueckhaltend, dies mit ACCESS Bordmitteln zu loesen; dies ist uebrigends auch der Grund fuer diesen Thread - Sync Threads gibt es ja eigentlich schon genug auf administrator.de
Hat jemand einen Vorschlag, wie das zu loesen waere??
Toolvorschlaege ebenfalls willkommen...
Allerdings kommt mir grad in den Sinn, wenn nun beide Benutzer jeweils einen Datensatz mit der gleichen Nummer anlegen, aber unterschiedlichen Inhalt hat, dann duerfte ich ja mit der SYNC-Idee nicht allzuweit kommen.
saludos
gnarff
zwei Rechner, zwei *mdb-Dateien.
Diese sollen am Ende eines Tages synchronisiert werden, damit beide Benutzer stets ueber die gleichen Datensaetze verfuegen.
Dummerweise handelt es sich um eine VB-Applikation die auf MS ACCESS 97 basiert, auf den Rechnern arbeitet jedoch ACCESS 2003. Daher bin ich ein wenig zurueckhaltend, dies mit ACCESS Bordmitteln zu loesen; dies ist uebrigends auch der Grund fuer diesen Thread - Sync Threads gibt es ja eigentlich schon genug auf administrator.de
Hat jemand einen Vorschlag, wie das zu loesen waere??
Toolvorschlaege ebenfalls willkommen...
Allerdings kommt mir grad in den Sinn, wenn nun beide Benutzer jeweils einen Datensatz mit der gleichen Nummer anlegen, aber unterschiedlichen Inhalt hat, dann duerfte ich ja mit der SYNC-Idee nicht allzuweit kommen.
saludos
gnarff
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 113236
Url: https://administrator.de/forum/access-dateien-synchronisieren-113236.html
Ausgedruckt am: 22.12.2024 um 07:12 Uhr
6 Kommentare
Neuester Kommentar
Servus,
per Tool - wüßte ich echt nicht - wie das "gut" geht.
Am einfachsten - ungetestet - würde ich folgenden Ansatz mal durchspielen.
Ich denke, das ist dann selbsterklärend und braucht keine Rems
Das einzigste, was noch fehlt, ist dann der Abgleich der beiden DBs untereinander.
Am einfachsten per At Befehl beide Systeme nachts gleichzeitig starten und die neuere DB auf den anderen kopieren und Shutdown.
Gruß
per Tool - wüßte ich echt nicht - wie das "gut" geht.
Am einfachsten - ungetestet - würde ich folgenden Ansatz mal durchspielen.
if exist x:\ net use x: /delete
if exist x:\ subst x: /delete
ping Rechnerx && net use x: \\rechnerx\dbpfad
if not exist x:\ subst x: lokalerrechner\dbpfad
x:\meine.mdb
:endIch denke, das ist dann selbsterklärend und braucht keine Rems
Das einzigste, was noch fehlt, ist dann der Abgleich der beiden DBs untereinander.
Am einfachsten per At Befehl beide Systeme nachts gleichzeitig starten und die neuere DB auf den anderen kopieren und Shutdown.
Gruß
Das einzigste, was noch fehlt, ist dann der Abgleich der beiden DBs untereinander.
Am einfachsten per At Befehl beide Systeme nachts gleichzeitig starten und die neuere DB auf den anderen kopieren und Shutdown.
Am einfachsten per At Befehl beide Systeme nachts gleichzeitig starten und die neuere DB auf den anderen kopieren und Shutdown.
Ist das ein Witz??
Ich starte Datenbank A um 8 Uhr, arbeite den ganzen Tag darin, und schließe sie um 18 Uhr. Ich starte Datenbank B um 19 Uhr, ändere kurz eine Telephonnummer und schließe sie gleich wieder. Wenn ich jetzt die neuere Datenbank (nämlich B) nachts zur neuen Grundlage auf beiden Rechnern mache, ist alles, was ich den ganzen Tag über in A gearbeitet habe, futsch.
Aber wozu überhaupt etwas abgleichen, wenn ohnehin beide über das Netzwerk in der gleichen Datenbank arbeiten. Denn das schlägst Du mit Deinem VB-Code doch vor, oder habe ich da was falsch verstanden?
Moin gnarff,
ich schließe ja selten die Möglichkeit einer Lösung aus, aber in diesem Falle, unter den genannten (bzw. vermuteten) Rahmenbedinungen...
--- wo ihr also letzten Endes eine Replikation zaubern wollt (oder meinetwegen Synchronisation) OHNE die ersten Schritte machen zu können, nämlich
... hey, wenn ihr diese Aufgabe in Eigenentwicklung zusammenklöppeln wollt, dann ist bei Fertigstellung ein neues ACCESS 97 auf dem Markt.
... obwohl, falls M$ bei den vierstelligen Versionsnummern bleibt, dann heißt es anders.
--> Abgesehen davon noch der Einwand: Alles, was in Richtung "Replikation" geht, setzt eigentlich eine direkte Rechnerverbindung voraus (Lan, Internet, whatever..).
Wenn diese da ist, warum dann nicht EINE Server-Nur-Daten-MDB und zwei lokale Client-Front-End-Nur-GUI-MDBs?
--> Falls es überhaupt ein Tool gibt, dass Dir weiterhelfen könnte, dann müsste es auf dieser Seite geben
--> und auch das ist eher indiskutabel, wenn die Clients nicht mal jeweils zwei in GUI und Daten getrennte Mdbs haben.
---> wenn alles unzumutbar ist und ihr eine mandantenfähige Client/Server-Appz braucht, dann steigt auf eine um. Sorry. Manche Sachen lassen sich nicht glaubwürdig nachstellen.
Oder kam Deiner Erinnerung nach in den Geschichten von "Robinson Cruesoe" oder "Kevin allein zu Haus" irgendwo ein flotter Dreier vor? Und wenn--> hey, es sind nur ausgedachte Geschichten..
Grüße und saludos
Biber
ich schließe ja selten die Möglichkeit einer Lösung aus, aber in diesem Falle, unter den genannten (bzw. vermuteten) Rahmenbedinungen...
- Zwei lokal/absolut asynchron über eine bonbonbunte Klicki-Bunti-Oberfläche gepflegte Datenbestände, an denen jeden Tag neue Datensätze hinzukommen
- aber wo beide BearbeiterInnen alle Datensätze sehen und ändern dürfen/sollen
- bei der ihr die Appz/die GUI nicht anpassen könnt
- und wo auch das Tabellendesign (insbesondere Primary Keys) tabu ist
--- wo ihr also letzten Endes eine Replikation zaubern wollt (oder meinetwegen Synchronisation) OHNE die ersten Schritte machen zu können, nämlich
- die Änderung einer der MDBs auf eine Master-Rep-DB
- und OHNE die Trennung von Appz und Daten in mehrere MDBs
- und OHNE die Erweiterung des Datenmodells um ein paar GUIDs und MandantenIDs und Timestamps....
... hey, wenn ihr diese Aufgabe in Eigenentwicklung zusammenklöppeln wollt, dann ist bei Fertigstellung ein neues ACCESS 97 auf dem Markt.
... obwohl, falls M$ bei den vierstelligen Versionsnummern bleibt, dann heißt es anders.
--> Abgesehen davon noch der Einwand: Alles, was in Richtung "Replikation" geht, setzt eigentlich eine direkte Rechnerverbindung voraus (Lan, Internet, whatever..).
Wenn diese da ist, warum dann nicht EINE Server-Nur-Daten-MDB und zwei lokale Client-Front-End-Nur-GUI-MDBs?
--> Falls es überhaupt ein Tool gibt, dass Dir weiterhelfen könnte, dann müsste es auf dieser Seite geben
- Trigeminal - Tools . Und denk jetzt nicht, es ginge auf dieser Seite um Probleme mit Gesichtsnerven. Da wohnt einer der deutschen Access bzw JET-Engine Päpste Micha Kaplan
- eine Seite mit vielen Links zu Access-Repllikation ist auf jeden Fall schwerinsoft
- Grundlagen speziell für ACCESS97-Replikation vom sympathischen PraktikantInnen-Beschäftiger FAQ-97-Repl
--> und auch das ist eher indiskutabel, wenn die Clients nicht mal jeweils zwei in GUI und Daten getrennte Mdbs haben.
---> wenn alles unzumutbar ist und ihr eine mandantenfähige Client/Server-Appz braucht, dann steigt auf eine um. Sorry. Manche Sachen lassen sich nicht glaubwürdig nachstellen.
Oder kam Deiner Erinnerung nach in den Geschichten von "Robinson Cruesoe" oder "Kevin allein zu Haus" irgendwo ein flotter Dreier vor? Und wenn--> hey, es sind nur ausgedachte Geschichten..
Grüße und saludos
Biber
Hallo gnarff,
ich sehe da keinen Grund zurückhaltend zu sein. Man sollte immer vorher eine Datensicherung machen. Dann bist du auf der sicheren Seite und hast keine Probleme, wenn mal was schief geht.
Grundsätzlich ist dir klar, dass du ggf. damit das komplette Programm himmelst? Je nach Art der Programmierung und Definition der Indexe/Schlüsselfelder kann es zu Inkonsistenzen kommen.
Da es sich anscheinend um eine Front- Backend -Lösung handelt, würde ich das Backend auf einen Server legen und von beiden Clients darauf zugreifen. Das ist auf jeden Fall besser, als eine Synchronisation.
btw sind mir in den letzen 10 Jahren keine Tools untergekommen die sowas für dich erledigen könnten!
Grüße aus Schönberg (Lübeck)
Wolfgang
(Netwolf)
ich sehe da keinen Grund zurückhaltend zu sein. Man sollte immer vorher eine Datensicherung machen. Dann bist du auf der sicheren Seite und hast keine Probleme, wenn mal was schief geht.
Grundsätzlich ist dir klar, dass du ggf. damit das komplette Programm himmelst? Je nach Art der Programmierung und Definition der Indexe/Schlüsselfelder kann es zu Inkonsistenzen kommen.
Da es sich anscheinend um eine Front- Backend -Lösung handelt, würde ich das Backend auf einen Server legen und von beiden Clients darauf zugreifen. Das ist auf jeden Fall besser, als eine Synchronisation.
btw sind mir in den letzen 10 Jahren keine Tools untergekommen die sowas für dich erledigen könnten!
Grüße aus Schönberg (Lübeck)
Wolfgang
(Netwolf)
Servus, nein das ist der Punkt "ungetestet"
Ich starte Datenbank A um 8 Uhr, arbeite den ganzen Tag darin, und
schließe sie um 18 Uhr. Ich starte Datenbank B um 19 Uhr,
ändere kurz eine Telephonnummer und schließe sie gleich
wieder. Wenn ich jetzt die neuere Datenbank (nämlich B) nachts
zur neuen Grundlage auf beiden Rechnern mache, ist alles, was ich den
ganzen Tag über in A gearbeitet habe, futsch.
Wenn ich dein Vorhaben richtig verstanden habe - es gibt nur 2 Systeme?
Aber wozu überhaupt etwas abgleichen, wenn ohnehin beide
über das Netzwerk in der gleichen Datenbank arbeiten.
über das Netzwerk in der gleichen Datenbank arbeiten.
Weil evtl. nicht sichergestellt ist, das RechnerX immer der erste ist, der an ist
Denn das schlägst Du mit Deinem VB-Code doch vor, oder habe ich da was
falsch verstanden?
Yupp - ist kein vbs - sondern bätch und auch nur ein Teil - der andere (für den anderen Rechner müßte ja auf RechnerY gemünzt werden)falsch verstanden?
Ergo - entweder 3. Rechner (Server) -oder WOL fähige Systeme vorausgesetzt...
Wenn RechnerX nicht an ist und von RechnerY auf die DB zugegriffen werden soll, dann WOL an RechnerX senden - warten bis er da ist und dann dort die DB starten.
Immer noch besser, als den Kram zu teilen - und die Tabellen in eine gespiegelte MYsql zu überführen - da bist du mit einem kleinen gebrauchten 3. Rechner preiswerter unterwegs.
Gruß
Die Ueberschrift ACCESS Dateien synchronisieren laesst den augenweitenden Rueckschluss zu, dass hier jemand versucht alles so zu machen wie es nicht zu sein hat, naemlich eine Arbeitsumgebung zu schaffen, wo die DB-Benutzer ueber simples Filesharing auf die Applikation zugreifen was der Garant fuer zukuenftige Probleme ist.
Eine DB hat in Frontend und Backend gesplittet zu werden, das haette ich auch mit groesstem Vergnuegen gemacht, wenn die VB-Applikation sich nicht ACCESS '97 sondern ACCESS 2003 bedient haette.
97 kann nicht mit 2003 und vizeversa, man muss also konvertieren. Das Konvertieren haette aber die Gefahr mitsich gebracht, dass die Appliaktion nicht mehr ordnungsgemaess gelaufen waere; wie Netwolf das schon richtig angemerkt hatte.
Es hagelte schon bei normaler Benutzung bestaendig VB-Laufzeitfehlermeldungen (53) und Can't Show Non-Modal Form where modal Form is expected (401) weil imho der timer loop frunzig programmiert wurde.
Wie auch immer, ich habe das Problem wie folgt geloest:
- Jeder Rechner hat die komplette Applikation installiert bekommen.
- Auf Rechner 1 laeuft sie auf C:
- Ordner auf C: im Netz freigegeben
- Da Rechner 1 sich bestaendig weigerte mit normalen calls auf sich zugreifen zu lassen und in der Netzwerkumgebung von Rechner 2 angezeigt zu werden, habe ich die Verbindung einfach erzwungen und die Dateneingabe von Rechner 2 auf Rechner 1 umgeleitet; mit \\ip_Rechner 1\pfad_zum_mdb_bak-file
Das ist nicht sonderlich performant, der Refresh dauert ewig, aber es funktioniert...
Der Rechner 1 mus z.Zt. noch immer eingeschaltet und die Datenbank geladen sein, damit auf Rechner 2 gearbeitet werden kann.
Ich glaube mich aber vage daran zu erinnern, dass man die Formulardaten in einem Cache zwischenspeichern kann und man es so einrichten koennte, dass diese uebernommen werden sobald die DB auf Rechner 1 wieder online ist - daran arbeite ich gerade.
Was die Robinson Crusoe und den flotten Dreier anbetrifft, so kann ich mir vorstellen, dass da die eine oder andere unschuldige Ziege dafuer herhalten musste...bei Kevin bin ich mir allerdings sicher, sonst haette der Film ja "Kevin und Freitag und eine Ziege allein zu Haus" geheissen...
Saludos
gnarff
Eine DB hat in Frontend und Backend gesplittet zu werden, das haette ich auch mit groesstem Vergnuegen gemacht, wenn die VB-Applikation sich nicht ACCESS '97 sondern ACCESS 2003 bedient haette.
97 kann nicht mit 2003 und vizeversa, man muss also konvertieren. Das Konvertieren haette aber die Gefahr mitsich gebracht, dass die Appliaktion nicht mehr ordnungsgemaess gelaufen waere; wie Netwolf das schon richtig angemerkt hatte.
Es hagelte schon bei normaler Benutzung bestaendig VB-Laufzeitfehlermeldungen (53) und Can't Show Non-Modal Form where modal Form is expected (401) weil imho der timer loop frunzig programmiert wurde.
Wie auch immer, ich habe das Problem wie folgt geloest:
- Jeder Rechner hat die komplette Applikation installiert bekommen.
- Auf Rechner 1 laeuft sie auf C:
- Ordner auf C: im Netz freigegeben
- Da Rechner 1 sich bestaendig weigerte mit normalen calls auf sich zugreifen zu lassen und in der Netzwerkumgebung von Rechner 2 angezeigt zu werden, habe ich die Verbindung einfach erzwungen und die Dateneingabe von Rechner 2 auf Rechner 1 umgeleitet; mit \\ip_Rechner 1\pfad_zum_mdb_bak-file
Das ist nicht sonderlich performant, der Refresh dauert ewig, aber es funktioniert...
Der Rechner 1 mus z.Zt. noch immer eingeschaltet und die Datenbank geladen sein, damit auf Rechner 2 gearbeitet werden kann.
Ich glaube mich aber vage daran zu erinnern, dass man die Formulardaten in einem Cache zwischenspeichern kann und man es so einrichten koennte, dass diese uebernommen werden sobald die DB auf Rechner 1 wieder online ist - daran arbeite ich gerade.
Was die Robinson Crusoe und den flotten Dreier anbetrifft, so kann ich mir vorstellen, dass da die eine oder andere unschuldige Ziege dafuer herhalten musste...bei Kevin bin ich mir allerdings sicher, sonst haette der Film ja "Kevin und Freitag und eine Ziege allein zu Haus" geheissen...
Saludos
gnarff
