Limites de la réplication

Lorsque vous utilisez la réplication de fusion avec les abonnés Microsoft SQL Server Compact 3.5, il existe plusieurs limites au niveau de la publication. Cette section décrit ces limites.

Restrictions des modifications de schéma sur l'Abonné

Vous pouvez apporter certaines modifications de schéma sur l'Abonné. Le tableau ci-dessous décrit les modifications de schéma possibles qui peuvent être ou non effectuées sur l'Abonné.

Configuration requise supplémentaire

Les règles suivantes s'appliquent aux Abonnés SQL Server Compact 3.5 :

• Utilisation de la mémoire

  Au cours de la synchronisation, après que la réinitialisation a été demandée, la taille de la base de données SQL Server Compact 3.5 risque d'être multipliée par deux par rapport à la taille de la base de données actuelle. Elle sera toutefois réduite après la synchronisation (selon votre stratégie de réduction automatique).

• Validation des filtres d'abonnement

  La validation des filtres permet au serveur de publication de vérifier la valeur du filtre de l'Abonné avant la synchronisation des données. Si la valeur du filtre a changé au niveau de l'Abonné, le serveur de publication requiert une réinitialisation au niveau de celui-ci. Lorsque vous synchronisez des données à l'aide de SQL Server 2008 R2, SQL Server Compact 3.5 peut utiliser la validation des filtres.

  Notes

  La propriété HostName spécifie la valeur de filtre dynamique de l'abonnement. Si vous souhaitez modifier la valeur de filtre dynamique de l'Abonné en spécifiant une nouvelle propriété HostName, vous devez appeler la méthode avant de procéder à la synchronisation Reinitialize .

• Respect de la casse

  À compter de SQL Server Compact 3.5 Service Pack 1, SQL Server Compact prend en charge la définition des classements respectant la casse au niveau de la base de données. Toutefois, les noms d'objets (tels que les noms de tables, les mots clés de langage, les fonctions et les affichages) ne sont pas traités comme respectant la casse dans une base de données SQL Server Compact, même si le classement respecte la casse.

  Autrement dit, les objets sont traités différemment dans une base de données SQL Server Compact et dans une base de données SQL Server. Par exemple, les deux tables MYTABLE et mytable sont traitées comme des objets différents dans une base de données SQL Server qui respecte la casse. Les mêmes noms de tables provoquent un conflit de nom dans une base de données SQL Server Compact. En revanche, deux valeurs telles que MYVALUE et myvalue ne provoquent plus de violation de clé primaire dans SQL Server Compact car elles sont traitées comme des valeurs différentes, tout comme dans une base de données SQL Server.

• Nombre de colonnes dans une table

  SQL Server Compact 3.5 alloue sept colonnes système pour le suivi. Toutefois, ces tables système n'entrent pas en ligne de compte dans le nombre maximum de colonnes.

• Contraintes NOT FOR REPLICATION

  SQL Server Compact 3.5 ne prend pas en charge l'option NOT FOR REPLICATION. Ne créez pas de contraintes à l'aide de cette option. Si, dans une base de données, des contraintes possèdent l'option NOT FOR REPLICATION, supprimez-les, puis recréez-les. Si l'option NOT FOR REPLICATION est spécifiée, la contrainte est créée sur l'Abonné SQL Server Compact 3.5, mais ne comprend pas la syntaxe NOT FOR REPLICATION.

• Délai de connexion

  Les abonnements SQL Server Compact 3.5 récupèrent des échecs de communication en redémarrant à partir du dernier bloc de données correctement transmis, sous réserve que la connexion soit restaurée dans la limite du délai d'attente configurable par l'utilisateur. Ainsi, la synchronisation est possible même si le transport sous-jacent n'est pas fiable ou est provisoirement non disponible.

• Instantanés

  SQL Server Compact 3.5 prend en charge les options d'emplacement d'instantané par défaut et alternatif. Pour spécifier un emplacement d'instantané alternatif, vous pouvez définir cette option à l'aide de la procédure stockée sp_addmergepublication ou par le biais de SQL ServerManagement Studio afin de modifier les propriétés d'une publication existante.

  • Pour utiliser la procédure stockée sp_addmergepublication

    Attribuez à l'option @snapshot\_in\_defaultfolder la valeur FALSE et à @alt\_snapshot\_folder l'emplacement du dossier alternatif pour l'instantané.

  • Pour modifier les propriétés d'une publication existante

    Dans la section Instantanéde la boîte de dialogue Propriétés relative à la publication, désactivez la case à cocher Placer les fichiers dans le dossier par défaut, activez la case à cocher Placer les fichiers dans le dossier suivant, puis spécifiez le nouvel emplacement.

  Notes

  SQL Server Compact 3.5 ne prend pas en charge l'option d'instantané compressé.

Pour plus d'informations sur les instantanés, consultez Configuration du dossier de fichiers d'instantanés.

Informations non propagées à un Abonné SQL Server Compact 3.5

Vous pouvez inclure les éléments suivants dans une publication SQL Server, mais ils ne sont pas propagés à l'Abonné SQL Server Compact 3.5 :

• Contraintes CHECK

• Propriétés étendues

• Procédures stockées

• Vues

• Fonctions définies par l'utilisateur

• Déclencheurs

Dans la mesure où la réplication SQL Server Compact 3.5 ne peut pas propager ces éléments, vous devez implémenter une logique équivalente dans une application SQL Server Compact 3.5. Ainsi, la base de données SQL Server Compact 3.5 demeure cohérente avec la base de données SQL Server. Par exemple, si la base de données SQL Server comprend une contrainte CHECK, l'application SQL Server Compact 3.5 doit implémenter la vérification correspondante dans le code d'application.

Création d'index dans une base de données SQL Server Compact 3.5 locale

Vous pouvez créer des index uniques dans une base de données SQL Server Compact 3.5 locale, même si cette base de données est un Abonné à une publication. Cela est particulièrement utile, mais la création d'index uniques peut entraîner des problèmes si le serveur de publication, qui ne comprend pas de contrainte unique sur une colonne, envoie des données non uniques à l'Abonné. Par exemple, vous pouvez disposer d'une table T avec des colonnes C1 et C2, la clé primaire existant sur la colonne C1.

Une synchronisation initiale a lieu sur la base de données SQL Server Compact 3.5. La synchronisation une fois terminée, un index unique est ajouté à la colonne C2 de la base de données d'abonnement. Aucune modification n'est apportée à la base de données de publication.

Au cours de la synchronisation suivante, SQL Server insère les lignes suivantes :

Dans ce cas, la synchronisation échoue, car le serveur de publication a tenté d'insérer des valeurs non uniques pour la colonne C2. La synchronisation échouera, jusqu'à ce que la contrainte unique soit supprimée de la base de données d'abonnement.