DB synchronisation (an erfahrene User)

Hallo,

folgendes problem:
es soll eine datenbank geben, die mitarbeiter sind unter der woche extern unterwegs und müssen was offline in die datenbank eintragen.
d.h. die daten von dem notebook müssen danach mit der hauptdatenbank synchronisiert werden.

microsoft sql server bietet sowas nicht an.
man kann nur (so wie ich mich informiert habe) in eine richtung die daten replizieren lassen. deshalb habe ich eine idee wie man es mit ms sql lösen kann:

folgende idee:
der mitarbeiter wird auf dem notebook eine replikation der datenbank haben DATENBANK A (um damit arbeiten zu können) und dazu eine leere datenbank DATENBANK B
wenn er daten einfügen will, werden sie in die leere datenbank eingefügt. (DATENBANK B) id wird über zeitstempel vergeben.

DATENBANK B (am anfang leere db) wird dann auf die zentral db repliziert.
wenn wir zb. irgenwas geändert haben, wird ein script geschrieben, der die geänderten (und auch neuen) daten auf der zentral DB modifiziert.
z.b. so: DATENBANK A muss was geändert werden. in DATENBANK B schreiben wir rein, dass der datensatz zb. mit id 1 geändert werden soll.

dh. der mitarbeiter muss immer replikation von DATENBANK B auf zentral DB durchführen. und dann von zentral DB auf DATENBANK A.
das muss von jedem mitarbeiter gemacht werden (natürlich nat der vorige mitarbeiter nicht die daten von dem nächsten mitarbeiter)

warum 2 Datenbanken und id als Zeitstempel? weil sonst die daten vom vorigen mitarbeiter überschrieben werden. (zeitstempel ändert sich jede sekunde - d.h. wir nehmen an, dass er einmalig ist - so lange kein mitarbeiter in der gleichen sekunde einen datensatz hinzufügt)

was meint ihr - würde es so funktionieren können oder habe ich da was übersehen?
(also grapfhische oberfläche will ich access verwenden und Datebank MS SQL)
(nur mit access zu arbeiten, ist zu gefährtlich obwohl da replikationfunktion gibt)

Moien

Ich nehm mal an es geht um Warenwirtschaft ?

man kann nur (so wie ich mich informiert habe) in eine
richtung die daten replizieren lassen. deshalb habe ich eine
idee wie man es mit ms sql lösen kann:

Aus deinem Text kann ich nicht so ganz entnehmen was du vor hast, deshalb:

Der Scherz bei der Aktion ist der Aufbau der DB B. Man sollte nicht absoluten Werte speichern, sondern die Änderungen. Bei absoluten Werten geht das in die Hose.

Beispiel für absolute Werte: Ware X ist 20x auf Lager. Ein Mitarbeiter M1 verkauft Ware X 5x , M2 die gleiche Ware 3x. In der Zentrale wird auch verkauft, sagen wir 2x. In B_M1 steht Ware noch 15x drin, bei B_M2 17x. Wenn M1 synchroniziert steht in der HauptDB 15x (falsch). Wenn M2 später synchroniziert steht in der HauptDB plötzlich 17x (noch falscher).

Das gleiche mit relativen Werten klappt problemfrei.

Und als eindeutigen Stempel nimmt man eine Zeit + fortlaufende ID + Mitarbeiterkennung. Bei Warenwirtschaft wird der Stempel beim sycnen nicht so wirklich gebraucht. Nur wenn Ware X plötzlich neagtiv wird zählt die Zeit.

cu

hallo,
vielen danke für ihren antwort.
das ist schon klar, dass es mit diesen beispiel nicht funktionieren würde. es geht um datensätze, die vorwiegend nicht verändert werden. und wenn, dann so gut wie nur von einem mitarbeiter d.h. bei sowas werden die daten in eine logdatei geschrieben, um sie später zu analysieren.

meine frage bezieht sich eher ob das mit ms sql realisierbar ist. dh. die zentraldatenbank muss einmal slave und einmal master sein.

Hi!

meine frage bezieht sich eher ob das mit ms sql realisierbar
ist. dh. die zentraldatenbank muss einmal slave und einmal
master sein.

Hm, wir haben das mal mit Oracle und Außendienstmitarbeitern gemacht; Stammdaten wurden in beide Richtungen aktualisiert (vordefinierte Regeln, bei mehreren Änderungen, konnte die „schlagende“ Änderung manuell ausgewählt werden, etc.); Transaktionsdaten wurden aufgrund von Buchungssätzen upgedatet …

Jahre später gab’s dann die Replication unter Oracle, die dies alles automatisierte - nach vorgegebenen Parametern …

Aber natürlich ist dies auch auf SQL-Server machbar, aber halt mit viel Schreibarbeit (=eigene Algorithmen für den Abgleich entwickeln)

Grüße,
Tomh