Access dans sa version 2010 dispose enfin d’un mécanisme s’apparentant aux triggers (déclencheurs) bien connus chez les SGBD poids lourds (SQL Server, Oracle,…).

Prenons un exemple avec le schéma des relations :

Étant donné un découpage de la région en territoires comportant des adresses.
Les territoires sont attribués à des colporteurs et dans le cadre de leurs attributions, ceux-ci effectuent des visites.

Les contraintes à vérifier ici sont les suivantes :

C1) Une visite effectuée dans le cadre d’une attribution doit être réalisée parmi les adresses faisant partie des adresses du territoire attribué
C2) On ne rend pas visite à une adresse si la seule personne qui y habite est un colporteur.

La contrainte à programmer est donc sur le couple {idAttribution, idAdresse} de la table Visite.

Une première tentative…

La seule contrainte C1 peut être assurée grâce au jeu de l’intégrité référentielle en modifiant le schéma (adresses et attributions identifiées relativement au territoire):

Pas forcément simple à gérer au niveau de l’IHM et il reste encore la contrainte C2 à programmer.

2ème tentative avec une macro de données :

Enregistrons une première requête,

qui retourne les couples (adresse, attribution) possibles. J’ai retiré les occurrences où l’adresse est celle d’un colporteur (critère PersonneQuiEstColporteur.idPersonne Est Null).

Sur l’évènement « Avant Modification » de la table Visite, on écrit la macro commentée suivante:

On teste…

Soit l’adresse n°4 ne fait pas partie du territoire de l’attribution n°3, soit elle en fait éventuellement partie mais c’est un colporteur qui est enregistré à cette adresse.

CQFD : l’action de donnée « DéclencherErreur » invalide la saisie/modification de la visite n°12 dans la table.