Tester présence d'enregistrements en cascade avant DELETE

Bonjour à tous,

Je suis en train de reprendre l'ensemble de mon code afin de le "simplifier" et de réduire les risques d'erreurs/oublis. (et aussi de continuer à apprendre !)

J'ai plusieurs formulaire permettant d'enregistrer, modifier ou supprimer des enregistrements dans différentes tables liées directement ou indirectement.
Lors de la suppression d'un enregistrement, je vérifie si celle-ci n'aura pas d'impact sur d'autres tables, à l'aide d'un DLookup(). Pour l'instant, j'ai écrit des lignes de codes différentes dans chaque formulaire, sachant vers quelle(s) table(s) aller chercher.
Je souhaite simplifier ce processus en faisant appel, à partir de chaque formulaire, à une Sub écrite dans un module. A partir du nom du formulaire, je peux retrouver facilement la table concernée. J'aurai également une manière d'identifier l'enregistrement à supprimer. (clé primaire+table)

Je souhaite donc que la fonction regarde dans un premier temps si la suppression affectera d'autres enregistrements dans d'autres tables (sans avoir à les nommer explicitement -contrairement à mon code actuel), ce qui doit être faisable sachant qu'Access affiche un message d'avertissement dans ces situations. (messages que je ne souhaite pas que l'utilisateur final puisse voir, il faut donc que je "traite" en amont)

Si la réponse est non, supprimer.

Si la réponse est oui, dans l'idéal, pouvoir récupérer le nom de la/les table(s) concernée(s), et le nombre d'enregistrements affectés pour chaque table. (afin de pouvoir personnaliser un message d'avertissement)

Merci de me faire savoir s'il manque des informations afin de pouvoir m'aiguiller vers une solution ! (et excusez-moi si le sujet à déjà été traité, je n'ai rien trouvé ni ici, ni ailleurs !)

Une bonne journée à tous,

Bonjour.

En théorie et en se basant sur la collections Relations on peut y arriver en faisant un parcours d'arbre en profondeur.

J'ai essayé et dans la réalité c'est finalement assez délicat et j'y ai renoncé.

Les problèmes que j'ai rencontré sont les suivants :

1. Les relations doivent avoir été crées toujours de la table de référence vers la table utilisatrice.
   Sinon, il m'a été impossible de créer l'arbre de dépendance.
2. Les relations de table avec elle-même posent un problème.
3. Les relations multiples avec une même table posent aussi un problème.

J'ai finalement fait une table manuelle des "cascades" (en fait une collection dans mon code mais l'idée est la même).
Cela m'a pris moins de temps que d'écrire du code qui gère tous les cas possibles et marche assez bien car j'ai peu de place où j'en ai vraiment besoin.

A+

Bonjour,
Désolé pour le temps de réponse, j'essayais de chercher comment votre méthode fonctionne, et je n'ai trouvé aucune solution qui me semble vraiment "simple", je crois que je n'arrive pas à visualiser la/les boucles nécessaires pour tester l'ensemble des relations de manière simple et sans contrainte de profondeur...


J'enregistre dans ma table index les champs : TblInitiale, TblLiée1, TblLiée2, ...

Avant d'effectuer une suppression dans la TblInitiale, je lance une boucle (première boucle) qui ira vérifier dans l'ensemble des Tblliées si il y a une valeur enregistrée, si oui, aller vérifier dans la Tbl correspondante la présence d'un enregistrement lié avec la valeur de TblInitial. (à partir de l'ID)
Dans le cas où certains sont trouvés, il me faudra lancer une autre boucle (seconde boucle) reprenant la première boucle pour chaque Tblliée impactée.
Il faudra ensuite réutiliser le modèle de la seconde boucle, avec la première imbriquée, pour tester le troisième niveau de cascade.
Et ainsi de suite....
Puis supprimer les "doublons" éventuellement trouvés

Je suis loin d'être doué, mais je ne vois pas comment ne pas ré-écrire la boucle autant de fois qu'il n'y a de niveau de profondeur au total pour ma base, et j'en suis donc arrivé à une solution tout à fait aussi usine à gaz qu'auparavant... alors que mon but est de simplifier au maximum.

Sans vouloir abuser, ni de votre temps, ni de votre matière grise, pourriez-vous partager le fruit de votre travail et/ou me diriger vers les outils nécessaires, la réflexion à mener ?

Bonjour.

Citation:

---

j'en suis donc arrivé à une solution tout à fait aussi usine à gaz qu'auparavant... alors que mon but est de simplifier au maximum.

---

C'est à peu près ma conclusion aussi.
Comme je l'ai dit j'ai finalement gérer seulement un sous-ensemble du problème.

Sinon, ce que j'ai fait avant c'est ce qu'on appelle un parcourt d'arbre en profondeur récursif (un appel qui appelle lui-même qui appelle lui-même qui appelle lui-même ... qui fini quand il n'y a plus d'enfant) qu'on peut résumer ainsi :

fonction SupprimerDonnees(prmTable)

pour tous les enfants de la table , exécuter SupprimerDonnnees(table enfant) 'appel récursif il faut supprimer les enfants avant de supprimer le parent
supprimer les données de prmTable

fin fonction

Pour amorcer la pompe, il faut fournir la liste des tables parents :

pour toutes les tables parent

executer SupprimerDonnees(table parent)

fin pour

A+

Merci bien pour votre réponse, l'idée de la fonction qui s'appelle elle-même me semble effectivement utilisable pour les suppressions, mais plus compliquée pour retrouver le nom des tables concernées, et le nombre d'enregistrements associés, et ce sans avoir de doublons.
Je ne vais pas avoir beaucoup de temps jusqu'au week-end prochain, je laisse donc le sujet en non-résolu, jusqu'à ce que j'ai pu me pencher sur la question.

N'y voyez aucun mal, mais j'ose espérer que dans ce délais quelqu'un apportera une solution plus "malléable" !

Bien à vous,

Citation:

---

j'ose espérer que dans ce délais quelqu'un apportera une solution plus "malléable" !

---

moi aussi.

C'est d'autant plus frustrant que Access sait le faire et qu'il ne nous laisse pas y accéder :-(.

A+

Bon... je passe le sujet en résolu, même si la solution reste du bricolage !

Merci en tout cas pour l'idée de la table, mais je vais m'en passer, je ne vois pas trop comment mettre cela en place, et je ne pense pas que ça change grand chose par rapport à ré-écrire le code systématiquement (dans chaque formulaire), si ce n'est, peut-être, un peu plus de liberté par la suite en cas d'ajout de nouvelles tables ! (ce qui est pas mal, mais pour le coup pas ma priorité actuelle)