Envoi de données d'un client vers un serveur

La transmission de type push d'un client vers un serveur comprend la propagation des modifications de Microsoft SQL Server Compact 3.5 vers une table SQL Server. Pour plus d'informations, consultez Méthode Push.

L'application doit avoir créé la table SQL Server Compact 3.5 locale en appelant la méthode Pull avec l'option de suivi activée.

Les méthodes Pull et Push suivies par RDA (Remote Data Access) utilisent un contrôle de concurrence optimiste. SQL Server ne conserve pas les enregistrements extraits verrouillés. Lorsque l'application appelle la méthode Push, les modifications apportées à la base de données SQL Server Compact 3.5 locale sont appliquées sans conditions à la base de données SQL Server. Ceci peut entraîner la perte de modifications apportées à la base de données SQL Server par d'autres utilisateurs.

Traitement par lot

RDA_BATCHOPTION spécifie si SQL Server Compact 3.5 doit traiter par lot les modifications envoyées à la table SQL Server. La valeur par défaut est BATCHINGOFF ; elle permet d'appliquer les modifications (insertions, mises à jour et suppressions) à la table SQL Server sous forme de transactions individuelles. La réussite d'une transaction ne dépend pas d'une autre transaction. BATCHINGON indique que toutes les modifications doivent être envoyées par le biais d'une transaction unique. Dans ce cas, toutes les modifications doivent réussir pour que la transaction réussisse. Si une modification échoue, l'ensemble de la transaction échoue et aucune modification n'est appliquée à la table SQL Server. Bien que BATCHINGON ne soit pas l'option par défaut, certains développeurs peuvent apprécier ce mécanisme simple lors de la création du code de résolution de conflits. Pour plus d'informations, consultez Détection et signalement des conflits RDA.

Les deux énumérateurs BATCHINGON et BATCHINGOFF renvoient toutes les erreurs à la table d'erreurs, pas seulement la première erreur qui se produit. Par exemple, si l'énumérateur BATCHINGON est spécifié et que trois modifications sur cinq échouent, aucune modification n'est appliquée et les trois échecs sont stockés dans la table d'erreurs. Si l'énumérateur BATCHINGOFF est spécifié, les mêmes trois échecs sont stockés dans la table d'erreurs et les deux autres modifications sont appliquées à la table SQL Server.

Transactions individuelles

Lors de transactions individuelles (option BATCHINGOFF), les conflits sont détectés au niveau de la ligne. La ligne en conflit est renvoyée à l'application et stockée dans une table d'erreurs spécifiée. Par exemple, si l'application tente d'envoyer une ligne non valide à SQL Server, la 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 dans la table d'erreurs, elle est supprimée de la base de données d'origine sur l'appareil. Vous devez configurer l'application de manière à autoriser l'utilisateur à corriger les données en conflit et les fusionner dans la base de données Windows Mobile d'origine.

Transactions par lot

RDA prend également en charge une option d'envoi par lot (option BATCHINGON) qui exige que toutes les lignes réussissent pour pouvoir traiter l'ensemble de l'envoi. Si une ligne échoue, l'ensemble de la transaction d'envoi échoue et aucune donnée n'est mise à jour. Les lignes en conflit sont copiées dans la table d'erreurs. Contrairement à l'envoi individuel, la base de données Windows Mobile d'origine reste inchangée. Vous devez configurer l'application de manière à autoriser l'utilisateur à corriger les données en conflit et les fusionner dans la base de données Windows Mobile d'origine. La table d'erreurs est automatiquement nettoyée avant qu'une ligne en conflit soit copiée. La table ne contient dès lors que les conflits de la dernière opération d'envoi.

Voir aussi

Autres ressources

Procédure : transmission de données de type push à l'aide de l'objet RDA (par programme)