Tél : 01 41 19 27 72 | Contact
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  allons 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é.  Le meilleur endroit est bien sûr la méthode intégrée 'action' des objets MR et TF.  Dans 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.  Nous 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:
method action(var eventInfo ActionEvent)
SWITCH
CASE eventInfo.actionClass() = DataAction :
SWITCH
CASEnbsp;eventInfo.id() = DataUnlockRecord or eventInfo.id() =DataPostRecord:
IF self.Touched then
IF tbAvantImputer_LO() = FALSE THEN
DISABLEDEFAULT
eventInfo.setErrorCode(canNotDepart)
RETURN
ELSE
DODEFAULT
IFeventInfo.errorCode() = 0 THEN
tbApresImputer_LO()
ENDIF
ENDIF
ENDIF
CASE nbsp;eventInfo.id() = DataLockRecord :
IF tbAvantVerrouiller_LO() = FALSE THEN
DISABLEDEFAULT
eventInfo.setErrorCode(userError)
ELSE
DODEFAULT
IFeventInfo.errorCode() = 0 THEN
tbApresVerrouiller_LO()
ENDIF
ENDIF
CASE nbsp;eventInfo.id() = DataInsertRecord :
IF tbAvantInserer_LO() = FALSE THEN
DISABLEDEFAULT
eventInfo.setErrorCode(userError)
ELSE
DODEFAULT
IFeventInfo.errorCode() = 0 THEN
tbApresInserer_LO()
ENDIF
ENDIF
CASE nbsp;eventInfo.id() = DataDeleteRecord :
IF tbAvantSupprimer_LO() = FALSE THEN
DISABLEDEFAULT
eventInfo.setErrorCode(userError)
ELSE
DODEFAULT
IFeventInfo.errorCode() = 0 THEN
tbApresSupprimer_LO()
ENDIF
ENDIF
ENDSWITCH
CASE eventInfo.actionClass() = EditAction :
CASE eventInfo.actionClass() = FieldAction :
CASE eventInfo.actionClass() = MoveAction :
CASE eventInfo.actionClass() = SelectAction :
ENDSWITCH
endmethod
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.  Par 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.
method tbAvantInserer_LO() LOGICAL
Valeur retour: FALSE si erreur dans la méthode ou si insertion non autorisée
....... votre programmation
nbsp;RETURN TRUE
endMethod
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).  La 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.