Accès multi-utilisateur et synchronisation
Comme Microsoft SQL Server Compact 3.5 (SQL Server Compact 3.5) prend en charge l'accès multi-utilisateur, un utilisateur peut continuer à utiliser une base de données lors de sa réplication. Cette possibilité peut entraîner des conflits avec les modifications provenant du serveur de publication, dénommés conflits de données locales, dont vous devez tenir compte lorsque vous développez des applications qui utilisent SQL Server Compact 3.5. De plus, certains scénarios de plateformes 64 bits ne prennent pas en charge l'accès simultané à un fichier de base de données avec des versions antérieures de SQL Server Compact. Pour plus d'informations sur les composants 64 bits, consultez Gestion d'applications de base de données 64 bits.
Effets de l'accès multi-utilisateur
Lorsque vous concevez une application qui utilise SQL Server Compact 3.5, vous devez tenir compte des effets de l'accès multi-utilisateur sur la base de données. Le tableau ci-dessous répertorie certaines des fonctionnalités courantes intégrées dans SQL Server Compact 3.5 et les problèmes associés à chacune d'entre elles.
| Fonctionnalité | Problème |
|---|---|
Verrouillage |
Au cours de la synchronisation, les modifications du serveur de publication risquent de ne pas être appliquées à la base de données de l'Abonné en raison des verrous de données. Si des modifications de données sont effectuées sur l'Abonné et qu'il existe des verrous de longue durée sur les données, la synchronisation risque d'échouer. Pour empêcher cette situation, ajoutez une logique à votre application qui empêche un utilisateur de modifier les données au cours de la synchronisation. |
Validation |
Si la validation est utilisée et que le nombre de lignes de la base de données SQL Server Compact 3.5 change au cours de la synchronisation, la validation échoue. Pour empêcher cette situation, ajoutez une logique à votre application qui empêche un utilisateur de modifier les données au cours d'une synchronisation avec validation. |
Réinitialisation |
Au cours de la réinitialisation d'un abonnement, la couche de réplication supprime et recrée toutes les tables utilisateur et système répliquées. Comme dans le cas des abonnements SQL Server, toute modification effectuée après le démarrage de la synchronisation est perdue lors de la réinitialisation. Pour empêcher cette perte de données, ajoutez une logique à votre application qui empêche un utilisateur de modifier les données au cours de la réinitialisation. |
Modifications de schéma |
Toutes les opérations DLL (modifications de schéma) doivent avoir un accès exclusif à la table. Une modification de schéma échoue si la table est utilisée par un autre processus. |
Modifications au cours de la synchronisation |
Si une modification de données a lieu au cours de la synchronisation, elle sera envoyée au cours de la prochaine synchronisation. Si une session de synchronisation entraîne un conflit local, la ligne est résolue en tant que niveau de ligne, même si le suivi de l'article est effectué au niveau des colonnes. |
Détection et résolution des conflits
Lorsque vous travaillez dans un environnement multi-utilisateur, des modifications peuvent avoir lieu au cours de la synchronisation et entraîner des conflits. SQL Server Compact 3.5 détecte les conflits côté client mais ne gère pas leur résolution. Les informations de conflit sont passées au serveur de publication afin que les conflits soient résolus au cours de la prochaine synchronisation.
La plupart des conflits sont résolus sur le serveur de publication au cours de la prochaine synchronisation. Toutefois, si un conflit d'intégrité référentielle (R/I) se produit, le serveur de publication demande une resynchronisation automatique sur l'appareil. Si ce comportement se produit, deux resynchronisations au maximum seront effectuées.
Pour plus d'informations sur la détection et la résolution des conflits, consultez Détection et résolution des conflits de réplication.
Utilisation de la propriété SubscriberConflicts
Les modifications apportées à la base de données locale au cours de la synchronisation peuvent entraîner un conflit local. Si une ligne provenant du serveur de publication ne peut pas être appliquée sur l'Abonné, cette erreur est considérée comme un conflit avec l'Abonné et la propriété SubscriberConflicts est définie. Dans le cas des Abonnés SQL Server, les conflits sont résolus côté Abonné. Toutefois, SQL Server Compact 3.5 ne contient pas de réconciliateur. Tous les conflits doivent être résolus sur le serveur de publication. Lorsque vous développez une application, vous pouvez la concevoir de telle sorte qu'elle examine la propriété SubscriberConflicts après chaque synchronisation. Si la propriété est définie sur une valeur différente de zéro, les données doivent être resynchronisées de sorte que le serveur de publication puisse résoudre les conflits.
Voir aussi
Concepts
Synchronisation des données (SQL Server Compact)
Synchronisation de données synchrones
Synchronisation asynchrone des données
Détection et résolution des conflits de réplication