Nous avons expliqué dans la note "Utilisation des contraintes d'intégrité Paradox" pourquoi la gestion des contraintes d'intégrité directement par paradox était à éviter. Nous &nbspallons montré ici comment Programmer celles-ci dans les objets Cadres de table (que nous appelerons du diminutif TF pour TableFrame) et Multi-enregistrements (diminutif MR pour Mult-Records). Nous préconisons d'utiliser au maximum ces objets pour la mise en place de vos champs dans vos fiches car vous bénéficiez alors pleinement de la richesse du modèle évènementitel de Paradox.

Tout d'abord, il faut piéger les évènements susceptibles dé déclencher la vérification d'une contrainte d'intégrité. &nbspLe meilleur endroit est bien sûr la méthode intégrée 'action' des objets MR et TF. &nbspDans cette méthode nous nous intéresserons aux actions relatives aux données (classe DataAction). En fait, l'instruction switch sur la classe d'action est destinée uniquement à organiser le code et n'est pas indispensable dans le cas présent. &nbspNous allons ensuite piéger les différents évènements relatifs au verrouillage (qui se produit avant qu'une modification soit autorisée), au déverrouillage (lorsqu'on veut imputer (enregistrer) les modifications sur l'enregistrement, à l'insertion et à la suppression. Pour chaque évènement, nous poserons un piège (que l'on appelera trigger pour faire pro) avant que l'évènement ne se produise et un second après que l'évènement ne se soit produit.

Le trigger avant à pour rôle d'autoriser ou non l'opération. Le trigger après à pour rôle de compléter l'opération (qui a déjà été effectuée par Paradox). Nous donnons des noms significaitfs à nos triggers (toujours les mêmes, ça simplifie la vie) et l'on obtient le code suivant pour la méthode action des objets MR et TF:

Puis (ou avant) nous renseignons les méthodes personnalisées tbAvantOperation_LO et tbApresOperation_LO que nous localisons également dans les objets TF et MR (cela permettra de les programmer de façon spécifique à chaque table). Le paramètre de retour indique le résultat de l'opération. &nbspPar exemple le retour de la méthode tbAvantInserer_LO permet de vérifier si l'insertion est permise. Un retour Tue autorisera l'opération alors qu'un retour False interdit l'opération.

Ainsi, on utilisera systématiquement les triggers Avant pour contrôler que l'opération est possible et les triggers Apres pour en tirer les conséquences. Il est important de bien comprendre la situation des triggers par rapport au Dodefault qui déclenche l'opération par Paradox.

Ainsi dans l'évènement DataInsertrecord, le Dodefault provoque l'insertion d'un enregistrement vierge (ou avec les valeurs par défaut pour la table). &nbspLa programmation dans tbApresInserer_LO a pour rôle de compléter cette insertion par défaut, par exemple en affectant un numéro d'incrément à un champ (cf note <link>Gestion des incréments) . A ce moment-là, l'utilisateur n'a pas encore effectué sa saisie.

En revanche, dans l'évènement DataDeleteRecord, DoDefault provoque la suppression physique de l'enregistrement. Si on veut effectuer des opérations suite à cette suppression, il est nécessaire de mémoriser les clés et autres informations qui seraient nécessaires dans tbAvantSupprimer_LO.