Replikation?

[Avallyn]

Hallo zusammen,

ich komme einfach nicht weiter.

Und zwar habe ich folgende Situation, mehrere Anwender haben eine SQL Express 2008 Datenbank auf ihren Arbeitscomputern. In dieser werden von jedem Anwender eigene Daten in einer Tabelle erfasst. Das Schema der betreffenden Tabelle ist bei allen gleich. Nun soll/muss ich diese Tabelle regelmäßig abfragen und auf einem weiteren Rechner im Netzwerk zusammenführen.

Wie würdet ihr das machen?
Ich dachte an einen SQL 2008 Server und eine Mergereplikation mit den einzelnen Arbeitscomputern als Abonennten; Trennung der Daten mithilfe eines Filters.
Oder würdet ihr als Datenbankkenner dazu raten das Microsoft Sync SDK einzusetzten und dies eher auf Programmierebene zu lösen?

Danke
Avallyn

[O. Helper]

Hallo Avallyn,

einfach ist das Thema so oder so nicht; man muss sich einige Gedanken über PrimaryKey (ggf. als Identity, besser als GUID) / FK usw. machen.

Replikation ist ein gutes Boardmittel des MS Sql Server, man muss nur reichlich konfigurieren, aber nichts programmieren.

Ms Sync ist gut geeignet, um einen lokalen Cache zu bilden; also zum Beispiel für Mobilgeräte, die nicht permant eine Verbindung haben.

Die Möglichkeiten zur Konfiktlösung ist aber in der Replikation umfangreicher als bei Ms Sync Framework.

Was nun wirklich für Dich besser ist, hängt von den Gegebenheiten und Anforderungen ab.

[Avallyn]

Also: Es gibt im Unternehmen mehrere Notebooks, die nur von Zeit zu Zeit mit dem Hausnetz verbunden sind, da sie auch beim Kunden verwendet werden. Über ein hausinternes Programm werden für / von jedem Anwender Zeiten in einer Datenbank (SQL Express 20008) erfasst. Diese Datensätze beinhalten u.a. den Namen des Anwenders und besitzen eine ID (Integer) als Primary Key. Ein zusammenführen der Daten sollte somit möglich sein. Jeder Anwender hat und soll in Zukunft nur Zugriff auf seine eigenen Daten haben. Diese könnte ich, wie gerade beschrieben, eindeutig filtern. Änderungen sollen nur vom Anwender durchgeführt werden können, also nur lokal auf seinem Notebook.

Kurz:
-> Es betrifft nur eine Tabelle beim Anwender Notebook
-> Die Daten sollen also zentral gespeichert / gesichert werden.
-> Konflikte sollten keine auftreten, da nur ein Anwender diese ändert.
-> Ich weiß nicht, wann sich ein Anwender mit dem Hausnetz verbindet. Kann täglich oder nur einmal in der Woche sein.

Es ist mir möglich sowohl die Datenbank anzupassen, als auch das Programm.

Ich hoffe, die Gegebenheiten und Anforderungen sind jetzt klarer.

Würdest Du mir für diesen Fall zu den Boardmitteln des SQL Servers raten, O. Helper?

Danke für Die Hilfe
Avallyn

[O. Helper]

Auf alle Fälle dazu raten würde ich nicht, aber ich kann es schon empfehlen, da es ein geringere Aufwand ist.

Einiges zu tun wirst Du aber trotzdem bekommen.
- IDs: Ich vermute mal, das sie als Identity ausgelegt sind? Als generiert jeder Client seine Ids und da es kein Gemeinschaftspool ist, werden Id doppelt vergeben. In der Replikation kann man je Client Bereiche für das Identity-Feld vergeben. Ist dann ein Pflege-Aufwand, man muss kontrollieren, ob die Id aus dem Bereich rauszulaufen drohen etc. Aus diesem Grunde nimmt man in solchen Szenarien auch GUID als Id. Die Merge-Replication fügt, wenn keine GUID in der Tabelle vorhanden ist, selbst eine hinzu. Die ist aber dann nicht der PK, sondern weiterhin Deine Id. Von daher wäre zu überlegen, ob Du es nicht gleich auf GUID umbaust.
- Push oder Pull-Abo? Push empfiehlt sich, bei Clients, die (fast) ständig am Netz hängen, der Server sendet dann proaktiv alle Änderungen an den Client. Kann der Server den Client 10 mal nacheinander nicht erreichen, wird das Abo gestoppt, man muss es von Hand (oder per Programm) neu starten. Bei Pull fragt der Client den Server regelmäßig, ob Änderungen vorliegen, egal ob oder ob nicht. Aber auch da muss man ggf. es von Hand anstarten.
Aber das kann man je Client einzeln einstellen.

Es gibt also einiges zu beachten, wie gesagt, am besten einmal in einem Kleinen Rahmen ausprobieren. Eine Replikation einer DB ist schnell eingerichtet und dann mal versuchsweise per SSMS Daten am Client / Server ändern und prüfen, ob alles wie gewünscht läuft.