Mehrbenutzerzugriff und Synchronisierung
Microsoft SQL Server Compact 3.5 (SQL Server Compact 3.5) unterstützt den Mehrbenutzerzugriff. Deshalb können Benutzer auch während einer Replikation weiter mit der Datenbank arbeiten. Jedoch können Konflikte bei Änderungen auftreten, die vom Verleger stammen. Diese werden als lokale Datenkonflikte bezeichnet. Sie müssen diese Konflikte berücksichtigen, wenn Sie Anwendungen entwickeln, die SQL Server Compact 3.5 verwenden. Einige 64-Bit-Plattformszenarien unterstützen außerdem keinen gleichzeitigen Zugriff auf eine Datenbankdatei mit älteren Versionen von SQL Server Compact. Informationen über 64-Bit-Komponenten finden Sie unter Verwaltung von 64-Bit-Datenbankanwendungen.
Auswirkungen des Mehrbenutzerzugriffs
Wenn Sie eine Anwendung entwerfen, die SQL Server Compact 3.5 verwendet, müssen Sie die Auswirkungen des Mehrbenutzerzugriffs auf die Datenbank berücksichtigen. In der folgenden Tabelle werden einige der in SQL Server Compact 3.5 integrierten Features aufgeführt, sowie die Probleme, die im Zusammenhang mit dem jeweiligen Feature auftreten können.
| Feature | Mögliches Problem |
|---|---|
Sperre |
Bei der Synchronisierung werden Änderungen auf dem Verleger von der Abonnentendatenbank aufgrund von Datensperren nicht übernommen. Wenn beim Abonnenten Datenänderungen vorgenommen und für die Daten langfristige Sperren festgelegt werden, schlägt die Synchronisierung möglicherweise fehl. Um dies zu vermeiden, sollten Sie Ihrer Anwendung die entsprechende Logik hinzufügen, die verhindert, dass ein Benutzer während der Synchronisierung Daten ändert. |
Überprüfung |
Wenn die Überprüfung verwendet wird und sich die Anzahl von Zeilen in der SQL Server Compact 3.5-Datenbank während der Synchronisierung ändert, ist ein Überprüfungsfehler die Folge. Um dies zu vermeiden, sollten Sie Ihrer Anwendung die entsprechende Logik hinzufügen, die verhindert, dass ein Benutzer während der Synchronisierung mit der Überprüfung Daten ändert. |
Erneute Initialisierung |
Bei der erneuten Initialisierung eines Abonnements werden alle replizierten Benutzer und Systemtabellen bei der Replikation gelöscht und neu erstellt. Wie bei SQL Server-Abonnements gehen bei einer erneuten Initialisierung alle Änderungen verloren, die nach dem Start der Synchronisierung vorgenommen wurden. Um diesen Datenverlust zu vermeiden, sollten Sie Ihrer Anwendung die entsprechende Logik hinzufügen, die verhindert, dass ein Benutzer während der erneuten Synchronisierung Daten ändert. |
Schemaänderungen |
Alle DDL-Vorgänge (Schemaänderungen) müssen über exklusiven Zugriff auf die Tabelle verfügen. Eine Schemaänderung schlägt fehlt, wenn die Tabelle von einem anderen Prozess verwendet wird. |
Änderungen während der Synchronisierung |
Wenn während einer Synchronisierung Daten geändert werden, werden diese Änderungen bei der nächsten Synchronisierung übertragen. Wenn eine Synchronisierungssitzung einen lokalen Konflikt verursacht, wird der Konflikt für die Zeile auf Zeilenebene gelöst, auch wenn die Nachverfolgung für den Artikel auf Spaltenebene erfolgt. |
Konflikterkennung und Konfliktlösung
In einer Mehrbenutzerumgebung können während einer Synchronisierung Änderungen auftreten, die Konflikte verursachen. SQL Server Compact 3.5 erkennt zwar Konflikte auf dem Client, behandelt jedoch keine Konfliktlösung. Vielmehr werden die Konfliktdaten an den Verleger weitergeleitet, damit dieser bei der nächsten Synchronisierung die Konfliktlösung durchführt.
Die meisten Konflikte werden bei der nächsten Synchronisierung auf dem Verleger gelöst. Tritt jedoch ein Konflikt der referenziellen Integrität (R/I) auf, dann fordert der Verleger automatisch eine erneute Synchronisierung auf dem Gerät an. In diesem Fall werden maximal zwei erneute Synchronisierungen durchgeführt.
Weitere Informationen zur Konflikterkennung und -lösung finden Sie unter Erkennung und Lösung von Replikationskonflikten.
Verwenden der SubscriberConflicts-Eigenschaft
Änderungen, die während einer Synchronisierung an der lokalen Datenbank vorgenommen werden, können einen lokalen Konflikt verursachen. Wenn eine Zeile des Verlegers beim Abonnenten nicht übernommen werden kann, wird dies als Abonnentenkonflikt betrachtet. In diesem Fall wird die SubscriberConflicts-Eigenschaft festgelegt. Bei SQL Server-Abonnenten werden Konflikte beim Abonnenten gelöst. SQL Server Compact 3.5 verfügt jedoch über keinen eigenen Konfliktlöser. Deshalb müssen alle Konflikte beim Verleger gelöst werden. Wenn Sie eine Anwendung entwickeln, können Sie diese so entwerfen, dass nach jeder Synchronisierung die SubscriberConflicts-Eigenschaft geprüft wird. Wenn diese einen Wert ungleich Null aufweist, müssen die Daten erneut synchronisiert werden, damit der Verleger die Konflikte lösen kann.
Siehe auch
Konzepte
Synchronisieren von Daten (SQL Server Compact)
Synchrone Datensynchronisierung
Asynchrone Datensynchronisierung
Erkennung und Lösung von Replikationskonflikten