Rapport entre Relations et Listes déroulantes

On pourrait s'imaginer qu'il existe un rapport entre une liste déroulante et une relation.
En fait non : on peut très bien avoir une liste déroulante basée sur une autre table, sans qu'il y ait de relation entre elles.
A contrario, on peut aussi avoir deux tables liées entre elles (avec même l'intégrité référentielle) sans qu'il y ait de liste déroulante.

Suppression d'une liste déroulante

Faisons un  test : détruisez la liste déroulante que vous avez faite sur PaysOrigine. C'est facile, il suffit de choisir Contrôle de l'affichage / Zone de texte dans ses propriétés :

---

Vous constaterez que toutes les autres propriétés de l'onglet Liste de choix ont disparu :

Lancez la table en mode saisie de données.
Essayez maintenant d'écrire, par exemple, Argentine comme PaysOrigine de Patrick Bruel : à l'instant de l'enregistrement, vous aurez le message d'erreur que vous connaissez.
Vous devrez donc connaître les pays de T_Pays par coeur, pour pouvoir les inscrire ainsi sans aucune erreur !
En résumé : les listes déroulantes n'ont rien à voir avec les relations avec intégrité référentielle, mais il faut admettre que ces deux concepts fonctionnent sacrément bien ensemble.

Comme l'amour et le sexe, finalement .

Du coup, remettez la propriété Contrôle de l'affichage de PaysOrigine à Zone de liste déroulante :  

Mise à jour en cascade

Maintenant, il y a quelques contraintes liées à cette intégrité référentielle ! Essayez ceci :

1. Dans la table T_Client, Refaites glisser le champ PaysOrigine juste sous Prenom, et fermez T_Client
2. Allez dans T_Pays, et ajoutez le nouveau pays Portugale (le e à la fin est une faute, mais faisons-là exprès)
3. Fermez T_Pays, et retournez dans T_Client. Dites que Coluche et Di Caprio viennent du Portugale

Nous sommes donc sous le coup d'un pays mal orthographié dans T_Pays, et par conséquent, également dans T_Client !

Que faire ?

Nous savons que dans T_Client, si nous essayons d'enlever le e de Portugale, nous aurons un message d'erreur, puisque l'intégrité référentielle nous empêche d'avoir la moindre différence entre les deux tables !
Et si nous nous rendions dans T_Pays pour retirer ce e à Portugale ? ... Vous pouvez essayer, mais vous aurez le même message d'erreur : comme des clients viennent de Portugale, pas question de modifier l'orthographe dans la table source non plus !

Que faire, que faire ???

On pourrait ajouter le nouveau pays Portugal (sans e) dans T_Client, et remplacer tous les Portugale par Portugal dans T_Client...
On pourrait ! ... Mais si nous avions 2'000 clients portuguais, ce sera pénible
On pourrait aussi supprimer l'intégrité référentielle, ce qui nous permet denlever le e de Portugal dans T_Pays sans qu'Access ne dise rien, puis remplacer aussi les Portugale par Portugal dans les PaysOrigine de T_Client...
On pourrait ! ... Mais ça revient un peu à retirer la police le temps de commettre une malversation et la remettre juste après... C'est très moyen !
Il existe une solution vraiment plus efficace !

Fermez toutes les tables éventuellement ouvertes et allez dans les relations. Double-cliquez sur la relation T_Pays - T_Client.

Ca affiche les propriétés de la relation.

Cochez Mettre à jour en cascade les champs correspondants, et OK.

Fermez les relations.
Allez dans T_Pays, et supprimez le e de Portugale. Fermez la table : il se laisse faire !
En fait, il vient de corriger l'orthographe de manière discrète et transparente dans nos 2 clients portuguais également ! Consultez T_Client pour vérifier si je dis vrai !
C'est donc une option bien utile !

Ca, c'était pour autoriser les modifications orthographiques.

Suppressions d'enregistrements en cascade

Mais que se passe-t-il si vous désirez carrément effacer Portugal de T_Pays ? Essayez ! Vous êtes gratifié de ce message d'erreur que vous connaissez.

En effet, c'est une autre histoire ! Corriger l'orthographe, c'est une chose ! Mais que faire lorsque l'enregistrement de référence n'existe carrément plus ?
Vous pourriez vous dire qu'Access n'a qu'à simplement effacer Portugal de Coluche et de Di Caprio, et le tour est joué !

Oui, vous avez raison, mais non, Access ne fait pas ça.

Fermez vos tables et allez dans les relations.

Double-cliquez à nouveau sur la relation T_Pays - T_Client, et, cette fois-ci, toujours dans la même boîte de dialogue, cochez Effacer en cascade les champs correspondants, et OK.

Fermez les relations.
Dans T_Client, nous avons actuellement : 11 clients, dont deux portuguais.

Fermez T_Client si vous l'aviez ouverte, et ouvrez T_Pays.

Supprimez Portugal.

Et voilà ! Access vient d'effacer Portugal dans T_Pays, mais également nos deux clients portuguais !

Fermez T_Pays, et ouvrez T_Client pour vous en convaincre : T_Client n'a plus maintenant que 9 clients au lieu de 11 :

Dangers de la suppression en cascade

pas question d'annuler cette suppression ! Si vous aviez eu 23'000 clients portuguais, ils se seraient volatilisés sans autre forme de procès ! Inutile de dire que cette case à cocher est à utiliser avec précaution !

En résumé, vous pouvez avoir deux tables reliées entre elles

1. avec intégrité référentielle
   ou
2. sans intégrité référentielle

S'il y a une intégrité référentielle, on dispose alors de deux autres possibilités :

1. Mettre à jour en cascade les champs correspondants
   et/ou
2. Effacer en cascade les enregistrements correspondants.