Ordre d'un DELETE CASCADE [Résolu]

[darnold]

Bonjour,

J'aimerai savoir si on peut contrôler l'ordre dans lequel SQL serveur gère les règles "ON DELETE CASCADE" lorsque qu'une table mère est liée à plusieurs tables filles elles-même liées entres elles.

Un exemple :
- Soit une table T0
- Soit une table T1 ayant une clé étrangère vers T0, avec suppression en cascade
- Soit une table T2 ayant une clé étrangère vers T0, avec suppression en cascade, et une clé étrangère vers T1, sans suppression en cascade.

Je souhaite supprimer une ligne de T0.
Normalement, grâce à mes cascades, SQL Server devrait supprimer les lignées liées dans les tables T1 et T2.
Deux scénario sont possible :
- Suppression de la ligne de T2
- Suppression de la ligne de T1
=> SUCCESS

- Suppression de la ligne de T1
=> ECHEC car T2 pointe vers T1

Donc ma question est : puis-je choisir l'ordre dans lequel SQL Serveur repercute les suppressions en cascade sur les tables filles ?

C'est un peu compliqué, j'espère que j'ai été assez clair !
Merci d'avance.

[SQLpro]

Votre question est idiote. Sachant qu'un ordre SQL est une transaction à part entière, soit tout sera supprimé, soit rien ne le sera. Il n'y a pas de demi mesure et l'ordre n'a donc aucune importance.

A +

[darnold]

Votre réponse l'est tout autant !

En gros ce que vous me dites, c'est que "ou bien ça marchera, ou bien sa me marchera pas". C'est une remarque pleine de profondeur, mais ça me fais de belles jambes.

Je reformule donc ma question : comme puis-je m'assurer que ça marche à tous les coups ?

[SQLpro]

Parce que c'est une transaction et que les transaction fonctionnent de manière atomique, c'est à dire en tout ou rien.

• Soit les contraintes permettent de supprimer toutes les informations de toutes les tables cascadées
• Soit une seule contrainte empêche de supprimer une seule ligne et dans ce cas rien n'est supprimé.

Bref, il serait temps pour vous de vous former su ce que sont les transactions dans les SGBDR !
A lire donc :
Les techniques des SGBDR
Transactions et niveau d'isolation

A +

[darnold]

Vous seriez aimable d'arrêter de me prendre de haut.
Vous n'avez toujours pas répondu à ma question : mon sujet demande "comment faire", et vous y répondez en disant "parce-que".

Je ne vous parle pas de transaction mais du fonctionnement du "on delete cascade". Le fait que tout cela fasse parti d'une transaction est très interessant, mais ça n'est pas de ça que je parle, ce que vous verriez si vous preniez le temps de lire vraiment ma question.

Vous êtes donc à coté de la plaque. Merci donc de me répondre vraiment et d'arrêter de me donner des leçons stupides !

[Oishiiii]

Envoyé par darnold

Donc ma question est : puis-je choisir l'ordre dans lequel SQL Serveur repercute les suppressions en cascade sur les tables filles ?

Non ce n'est pas possible.

J'ai fait quelque tests, ça fonctionne sans soucis.
SQL Server semble se débrouiller tout seul pour gérer ce genre de références "circulaires" (ou en tout cas plusieurs chemins de cascade et dépendances).
Donc rien à faire.

Sinon si vous n'êtes pas convaincu désactivez la FK sur t2 référencant t1 avant la suppression dans t0 :

Code :

ALTER TABLE t2 NOCHECK CONSTRAINT FK_t2_vers_t1

Ou alors, enlevez les CASCADE et utilisez un trigger INSTEAD OF pour faire les suppressions vous même.

[darnold]

SQL Server semble se débrouiller tout seul pour gérer ce genre de références "circulaires" (ou en tout cas plusieurs chemins de cascade et dépendances).
Donc rien à faire.

Ok, j'avais bien noté que il semblait se débrouiller tout seul, mais je ne savais pas si c'était un coup de bol ou s'il était capable de gérer le bazar tout seul.

Sinon la solution du "ALTER TABLE t2 NOCHECK CONSTRAINT FK_t2_vers_t1" me parrait bonne aussi.

Je passe le sujet en résolu.
Merci !