Hallo! > Mach hier doch mal ein paar Vorschl�ge.... > Ich habe auf beiden Seiten SQL-Servers (bzw. MSDE). > Ich habe eine Vielzahl von Clients und Eine Server-DB > Ich will nun, da� die Client-DB's in Intervallen von einigen > Minuten sich mit der Server-DB abgleichen. Hierzu ben�tige > ich eine SQL-Abfrage, da jeder Client anhand einer ID erkannt wird ...
Nimm einen SQL-Server als Replication-Master und definiere im Enterprise-Manager die zu publizierenden Tabellen. F�r regelm��ige Synchronisationen w�rde ich Push-Abonnements einsetzen, der Server f�hrt also nacheinander mit allen Clients Merge-Replikationen durch. Daf�r ist dann keine Zeile ASP bzw. ASP.NET erforderlich, das wiederholte Aufrufen der Task regelt der SQL Server Agent nach Deinen Vorgaben. Wenn der Replication-Master ebenfalls im Internet steht, schickt er Dir die Protokolle als E-Mail, idealerweise steht er aber zumindest in der Testphase lokal. Besch�ftige Dich ziemlich gr�ndlich mit der ausf�hrlicheb SQL Server Online Dokumentation zum Thema Replikation und nimm zum Testen eine kleine Datenbank und zun�chst mal eine einzelne Tabelle. Auch wenn Du die Synchronisation immer noch selber machen willst, solltest Du das Kapitel in der Dokumentation komplett durcharbeiten. Benutze GUIDs als Primary-Key f�r Tabellen, die garantiert nicht gemerged werden sollen (Bewegungsdaten) und normale Primary-Keys f�r Stammdaten. Wenn z. B. ein Benutzername in einer Tabelle eindeutig sein soll, dann ist das auch der Primary-Key. Mit IDENTITY-Werten funktioniert das Mergen nicht automatisch. Wenn bei der Replikation auch Tabellenverkn�pfungen aktualisiert werden m�ssen, w�rde ich immer ausschlie�lich die Standard-Funktionen des SQL Server nutzen. Stell Dir das mal mit IDENTITY-Werten vor: Beide Datenbanken starten synchron und dann werden in jeder Datenbank mehrere Datens�tze hinzugef�gt, die dann den gleichen IDENTITY-Wert erhalten, aber mit v�llig verschiedenen und unabh�ngigen Inhalten in den anderen Spalten. Ist der IDENTITY-Wert jetzt Primary-Key, dann �berschreiben sich die Daten gegenseitig und das gilt dann auch f�r die Daten in den verkn�pften Tabellen. Benutzer A f�gt einen Datensatz mit IDENTITY 4711 ein, Benutzer B auch, aber etwas sp�ter. Benutzer B "gewinnt", der Datensatz von Benutzer A verschwindet. Bei den verkn�pften Werten ist dann aber Benutzer A schneller als Benutzer B. Das Endergebnis ist dann Chaos: Stammdaten von Benutzer B mit verkn�pften Daten von Benutzer A. F�r die automatische Replikation nimmt man deshalb normale Primary-Keys oder GUIDs; au�erdem k�nnen automatisch Timestamps auf Datensatz- oder Spaltenebene und benutzerabh�ngige Priorit�ten zur automatischen Bearbeitung von Replikationskonflikten definiert werden. Bei Konflikten werden automatisch Tabellen erzeugt, die die Konflikte exakt beschreiben. Diese k�nnen dann mit dem Konfliktl�sungs-Manager des SQL Server oder mit eigenen Applikationen bearbeitet werden. Wenn Du Replikation auf Spaltenebene definierst, gibt es nur dann Konflikte, wenn tats�chlich zwei verschiedene Benutzer gleichzeitig den gleichen Spaltenwert modifizieren. Timestamps alleine reichen also nicht. F�r eine saubere Synchronisation ist das Datenbankdesign sehr wichtig, nicht zu vergessen das Synchronisieren der Rechnerzeit, sonst n�tzen die TimeStamps gar nichts. Freundliche Gr��e Joachim van de Bruck | [aspdedotnet] als [email protected] subscribed | http://www.dotnetgerman.com/archiv/aspdedotnet/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.dotnetgerman.com/listen/aspDEdotnet.asp
