Discussion :

[Tidus159]

Bonjour,

je souhaite (pour m'épargner plusieurs heures/journées de travail -même si c'est pas super bien d'après ce que j'ai googlé-) mettre en place un Trigger INSTEAF OF UPDATE pour gérer un cas sur une table.
(En l’occurrence pour être bien complet, à cause d'un problème de conception une colonne NOM est devenue clef étrangère dans plusieurs tables)
Je veux donc gérer mon trigger insteaf of update de cette façon :

Si c'est une mise à jour du NOM
alors RetenirLesLignesDesTablesAyantCetteFk
SetCetteFkANull
fin

FAIRE LA MISE A JOUR STANDARD

RemettreLesNouveauxNomDansLesColonnes

Super moche, j'en conviens.

J'aimerais savoir s'il y a un moyen d'appeler l'update par defaut qui aurait été joué sans ce trigger ? Est-ce possible ?
(Je n'aimerais pas lors d'une modification de structure de ma table (ajout d'une colonne), devoir modifier ce trigger ?

Merci

[Tidus159]

J'ai posté peut-être un peu vite malgré mes recherches : ON UPDATE CASCADE semble faire ce que je désire.
Par contre, il n'est pas possible d'avoir plusieurs clef étrangère en CASCADE, donc il faudra certainement que je code ma première idée donc ma question reste valable.

[CinePhil]

Par contre, il n'est pas possible d'avoir plusieurs clef étrangère en CASCADE

Que voulez-vous dire par là ?

Si une colonne est référencée par plusieurs clés étrangères, celles-ci peuvent toutes être en ON UPDATE CASCADE et la mise à jour de la colonne de référence entraînera la mise à jour de toutes les clés étrangères qui y font référence.

[Tidus159]

Bonjour Cinéphil,

après mes quelques recherches, j'ai pu voir que l'on ne pouvait pas avoir plusieurs ON CASCADE de FK sur la même colonne dans une table sous MS SQL Server

cf. http://stackoverflow.com/questions/8...-cascade-paths

Je te donne un exemple pour être plus explicite

T1 (id, code)
T2(id, codeT1EtatActivation#, codeT1EtatDesactivation#)

Le ON CASCADE ne peut pas être défini pour les 2 colonnes FK.

A+

[SQLpro]

Ce qui est tout à fait logique car il faudrait pouvoir définir la priorité.

Néanmoins, vous pouvez y arriver par déclencheur.

En revanche cette situation est anormale. Vous ne devriez jamais être dans ce cas. Votre modèle de données est incohérent.

Donnez-nous l'exemple concret qui justifierait un tel comportement. je serais curieux de voir cette horreur !

A +

[Tidus159]

Bonjour SQLPro,

tu as raison, c'était une question de paresse... et c'était moche.
La structure de la BD actuelle avait 3 colonnes d'états redondantes... et par paresse je ne voulais pas corrigé cette conception.

Cependant après avoir vu les différents problèmes (et la complexité du problème), je me suis lancé dans la mise en place des ids à la place de ces colonnes redondantes... (ce qui implique plusieurs jours de dev -sql en dur dans le code- et de multiples bugs potentiels)

A+