Gestion des contraintes liées au serveur

De RAD Studio
Aller à : navigation, rechercher

Remonter à Transmission de paramètres à l'ensemble de données source

Lorsqu'un serveur de base de données définit des contraintes sur la validité des données, il est utile que l'ensemble de données client les connaisse. Ainsi, l'ensemble de données client peut garantir que les modifications apportées par l'utilisateur n'enfreignent pas les contraintes établies par le serveur. Il s'ensuit que de telles violations ne sont jamais transmises au serveur de la base de données où elles auraient été rejetées. Cela signifie que les mises à jour générant des erreurs lors du processus de mise à jour sont moins nombreuses.

Indépendamment de la source des données, vous pouvez dupliquer les contraintes du serveur en les ajoutant explicitement à l'ensemble de données client. Ce processus est décrit dans Définition de contraintes pour les valeurs des données.

C'est cependant plus pratique si les contraintes du serveur sont automatiquement incluses dans les paquets de données. Car vous n'avez pas à spécifier explicitement les expressions ni les contraintes par défaut, et l'ensemble de données client change les valeurs qu'il rend obligatoires lorsque les contraintes du serveur changent. Par défaut, voici ce qu'il se produit exactement : si l'ensemble de données source est averti des contraintes du serveur, le fournisseur les inclut automatiquement dans les paquets de données et l'ensemble de données client les impose lorsque l'utilisateur poste ses modifications dans le journal de modifications.

Remarque :  Seuls les ensembles de données qui utilisent le BDE peuvent importer des contraintes à partir du serveur. Cela signifie que les contraintes du serveur ne sont incluses dans les paquets de données que si vous utilisez TBDEClientDataSet ou TClientDataSet avec un fournisseur qui représente une base de données basée sur le BDE. Pour plus d'informations sur la façon d'importer les contraintes du serveur et d'empêcher un fournisseur de les inclure dans les paquets de données, voir Gestion des contraintes du serveur.

Remarque :  Pour plus d'informations sur l'utilisation des contraintes lorsqu'elles ont été importées, voir Utilisation des contraintes du serveur.

Bien que l'importation des contraintes et des expressions du serveur soit une fonctionnalité de grand intérêt, qui aide une application à préserver l'intégrité des données, il y a des circonstances où apparaît la nécessité de les désactiver de manière provisoire. Par exemple, si une contrainte du serveur est basée sur la valeur maximale en cours dans un champ et si l'ensemble de données client utilise la lecture incrémentale, la valeur maximale en cours dans l'ensemble de données client peut être différente de la valeur maximale sur le serveur de la base de données et les contraintes appelées différemment. Dans un autre cas, si un ensemble de données client applique un filtre aux enregistrements quand des contraintes sont activées, ce filtre peut provoquer des interférences indésirables avec les conditions des contraintes. Dans chacun de ces cas, une application peut désactiver le contrôle des contraintes.

Pour désactiver temporairement les contraintes, appelez la méthode DisableConstraints. A chaque appel de DisableConstraints, un compteur de références est incrémenté. Tant que la valeur de ce compteur est supérieure à zéro, les contraintes ne sont pas appliquées sur l'ensemble de données client.

Pour réactiver les contraintes pour l'ensemble de données client, appelez la méthode EnableConstraints de l'ensemble de données. Chaque appel à EnableConstraints décrémente le compteur de références. Quand ce compteur atteint la valeur zéro, les contraintes sont à nouveau activées.

Conseil :  Appelez toujours DisableConstraints et EnableConstraints dans des blocs appariés pour garantir que les contraintes sont activées quand vous souhaitez qu'elles le soient.

Voir aussi