Détection et signalement des conflits RDA

Le service RDA (Remote Data Access) de Microsoft SQL Server Compact 3.5 offre un mécanisme de signalement de conflits limité pour les lignes qui ne peuvent pas être mises à jour sur l'ordinateur qui exécute SQL Server lors d'une opération de transmission de type push.

Important

Les lignes en conflit dans RDA sont strictement définies comme étant des opérations d'insertion, de mise à jour ou de suppression qui échouent en raison d'une erreur lors de leur envoi de SQL Server Compact 3.5 vers la table SQL Server. Les modifications apportées aux données par différents utilisateurs ne sont pas considérées comme des conflits si elles n'entraînent aucune erreur.

Bien que RDA ne fournisse pas de résolveur spécifique comme le fait la réplication, SQL Server Compact 3.5 génère une table d'erreurs qui capture toutes les lignes en conflit. Vous pouvez spécifier la table d'erreurs dans le cadre de la méthode Pull. Toute erreur qui se produit lors de l'envoi de données est enregistrée dans cette table. À l'aide de celle-ci, vous pouvez développer des applications pour gérer la détection et le signalement des conflits.

Les modifications apportées à la base de données SQL Server Compact 3.5 qui sont envoyées au serveur sont appliquées dans l'ordre dans lequel elles sont reçues. La table SQL Server est mise à jour pour refléter les modifications apportées par le dernier utilisateur.

Dans RDA, un conflit existe lorsqu'une ligne ne peut pas être envoyée de SQL Server Compact 3.5 vers SQL Server. RDA prend uniquement en charge le suivi au niveau des lignes. Par conséquent, certaines lignes réussissent et d'autres échouent, selon les options sélectionnées dans une méthode Push. Pour effectuer le suivi des conflits dans RDA, spécifiez TRACKINGON ou TRACKINGON_INDEXES dans la méthode Pull.

Vous pouvez éviter des conflits et des erreurs lorsque vous utilisez des tables suivies par RDA en filtrant correctement les tables et en utilisant une connexion réseau stable lors de la propagation des données.

Raisons des conflits RDA

Les modifications apportées à une ligne ne peuvent pas être appliquées au serveur pour les raisons suivantes :

• RDA effectue le suivi des opérations d'insertion, de mise à jour et de suppression spécifiquement pour chaque ligne qui a été modifiée dans la table suivie sur l'appareil. Par conséquent, si une ligne est insérée sur le client avec la même valeur de clé primaire qu'une ligne qui a également été insérée sur le serveur dans la même table, l'envoi des données du client va échouer et générer une erreur, car l'insertion a déjà eu lieu.

• Si les données n'ont pas été correctement partitionnées pour chaque utilisateur, un utilisateur peut supprimer une ligne alors qu'un autre tente de la mettre à jour.

• L'envoi de lignes au serveur peut également échouer, entraînant des erreurs si un envoi antérieur a été interrompu. Par exemple, un utilisateur démarre l'envoi de ses données au serveur, qui contiennent des insertions, et, au cours de l'envoi, la connectivité réseau est perdue. Le client affiche un message indiquant que l'envoi a échoué en raison de la perte de la connectivité réseau. Toutefois, les modifications ont été appliquées au serveur. Lorsque le client récupère la connectivité réseau et que l'utilisateur tente d'effectuer un second envoi des mêmes données, l'application de certaines lignes échoue, car celles-ci ont été insérées lors de l'envoi précédent. Dans ce cas, l'application doit ignorer toutes les erreurs de la table d'erreurs qui correspondent à des échecs provoqués par une clé primaire dupliquée dans le cadre du second envoi.

Tables d'erreurs

RDA effectue le suivi des conflits de lignes qui n'ont pas pu être appliquées au serveur en raison d'une erreur, en renvoyant et en stockant les erreurs dans une table d'erreurs de la base de données SQL Server Compact 3.5 avec la ligne qui a échoué. Vous définissez cette table dans la méthode Pull. Ensuite, si des erreurs se produisent lors d'une opération d'envoi des données (push), elles sont stockées dans la table d'erreurs.

Lorsque vous utilisez la méthode Push, si une ligne ne peut pas être appliquée au serveur en raison d'une erreur, telle qu'une clé primaire dupliquée, vous référencez le nom de la table d'erreurs que vous avez initialement définie dans la méthode Pull pour résoudre la ligne. La propriété ErrorTableName de la méthode Pull spécifie le nom de la table où les erreurs d'envoi doivent être stockées. La table d'erreurs est créée immédiatement, mais elle ne contient initialement aucune ligne. La propriété ErrorTableName peut être uniquement spécifiée lorsque TRACKINGON ou TRACKINGON_INDEXES est spécifié dans la méthode Pull.

Si une erreur se produit, car une ligne ne peut pas être appliquée pendant la méthode Push, SQL Server Compact 3.5 insère un enregistrement dans la table pour chaque erreur qui se produit. En plus de toutes les colonnes de la table de base de données, trois colonnes supplémentaires sont ajoutées pour identifier les raisons et le moment de la production de l'erreur. La colonne s_ErrorDate spécifie la date et l'heure auxquelles l'erreur s'est produite. La colonne s_OLEDBErrorNumber spécifie le HRésultat de l'erreur qui s'est produite lors de l'application de la ligne au serveur. La colonne s_OLEDBErrorString est une description de l'erreur. Lorsque la méthode Push se termine et que des erreurs se sont produites lors de sa tentative d'application des lignes au serveur, un avertissement (SSCE_WRN_RDAERRORROWSRETURNED, valeur 28800) est signalé à l'application, qui peut alors examiner la table d'erreurs pour déterminer la cause des erreurs.

Gestion des tables d'erreurs

Les tables d'erreurs sont automatiquement supprimées si la table suivie par RDA est supprimée, même s'il existe encore des lignes dans la table d'erreurs. Le développeur doit résoudre les lignes qui sont considérées comme des conflits, car celles-ci ne peuvent pas être appliquées au serveur.

L'actualisation des données sur l'appareil peut être nécessaire pour résoudre correctement l'erreur qui s'est produite lors de l'envoi initial des données au serveur. Il est recommandé de mettre en cache les données de la table d'erreurs, de sorte à ne pas les perdre lorsque vous supprimez la table suivie. Vous pouvez également extraire les données actualisées vers une table dont le nom est différent de celui de la table suivie d'origine.

Résolution des erreurs après un envoi de données

L'erreur qui est stockée dans la table d'erreurs avec la ligne qui a échoué décrit les raisons pour lesquelles l'insertion, la mise à jour ou la suppression de la ligne a échoué sur le serveur. Selon l'erreur, il peut être très important de connaître l'état actuel des données sur le serveur. L'application doit être à même de gérer cette situation, car la suppression de la table suivie a entraîné la suppression de la table d'erreurs.

Erreurs et transactions individuelles (hors lot)

Au cours des transactions individuelles (option BATCHINGOFF lorsque vous utilisez la méthode Push), les conflits sont détectés au niveau des lignes. La ligne en conflit est renvoyée à l'application et elle est stockée dans une table d'erreurs spécifiée. Par exemple, si l'application tente d'envoyer une ligne non valide à SQL Server, cette ligne est renvoyée à l'application et stockée dans la table d'erreurs avec un message d'erreur indiquant le conflit.

Lorsqu'une ligne en conflit est renvoyée à la table d'erreurs, elle est supprimée de la table d'origine. Étant donné que la table n'est pas conservée dans son état d'origine, il est un peu plus difficile de résoudre le conflit qui s'est produit. Vous devez concevoir l'application de sorte que l'utilisateur puisse corriger les données en conflit. Cela peut impliquer une nouvelle extraction de la table sur le serveur pour résoudre correctement la situation.

La suppression de la table sur l'appareil entraîne celle de la table d'erreurs. Vous devez mettre en cache les lignes de la table d'erreurs dans un emplacement temporaire ou extraire les données du serveur vers une table distincte. Étant donné que les lignes qui posent problème sont déplacées en dehors de la table sur la base de données SQL Server Compact 3.5, il est important que la table soit réactualisée avec les données correctes du serveur. Si la ligne qui a échoué a été initialement mise à jour, il doit s'agir d'une nouvelle mise à jour de la même ligne pour que la ligne réussisse lors de l'envoi suivant. Si la ligne a été mise à jour mais qu'elle a été supprimée sur le serveur, elle doit être ajoutée de nouveau à la table et renvoyée pour que l'insertion réussisse.

Erreurs et transactions par lot

RDA prend également en charge un envoi par lot (option BATCHINGON lorsque vous utilisez la méthode Push) qui nécessite que toutes les lignes réussissent pour que l'envoi complet soit traité. Si une ligne échoue, la transaction d'envoi entière échoue et aucune donnée n'est mise à jour. Les lignes en conflit sont copiées dans la table d'erreurs. Il s'agit de l'option conseillée, car elle permet l'utilisation d'un mécanisme un peu plus simple pour résoudre le conflit. Contrairement à l'envoi individuel (hors lot), la base de données Microsoft Windows CE d'origine reste intacte. Vous devez concevoir l'application de sorte que l'utilisateur puisse corriger les données en conflit et les refusionner dans la base de données Windows CE d'origine. Étant donné que la ligne d'origine reste intacte, selon l'erreur, il n'est peut-être pas être nécessaire de réextraire immédiatement les données du serveur pour déterminer la résolution de la ligne. Par exemple, si la ligne a échoué en raison d'une violation d'intégrité, la ligne sur l'appareil peut être mise à jour et la méthode Push appelée pour tenter d'envoyer les données au serveur. Cette option permet également une maintenance plus propre, car la table d'erreurs est automatiquement nettoyée avant la copie d'une ligne en conflit. Seuls les conflits issus de la dernière opération d'envoi (push) se trouvent dans la table.