Triggers og Cascade Delete, Execution Order

<<Hvad udføres først en After Delete Trigger på A eller den Cascade delete på B der peger på A?>>
En After Delete Trigger køres efter rækken er slettet, og dermed også efter at eventuelle relationer med cascade delete er slettet.

<<Kan man styrer rækkefølgen på Cascade Deletes, således at B's cascade delete som peger på A udføres før C's cascade delete der også peger på A?>>
Dette kan du ikke styre, og jeg kommer ikke på noget eksempel på hvor det kan være nødvendigt. Hvis du absolut bliver nød til at styre rækkefølgen, kan du bruge en trigger til at slette refererende rækker i stedet for en cascade delete relation.

Kan du eventuelt komme med en forklaring på hvorfor du ønsker at styre rækkefølgen?

Ja, men det kan løses med en trigger som du siger, (Derfor spm 1 var der)...
Så det er ikke noget problem i det tilfælde, andet end at det naturligvis er lidt mere arbejde...

Men du har ikke nogle links til dokumentation på emnerne?... har ledt og ledt... og ikke fundet noget... ellers må du godt smide et svar.

Lidt svært at forklarer hvorfor, men PT har vi en masse tables der refererer A, som alle har en cascade delete, så have vi igen en række tables der refererer nogle af disse tables, igen med en cascade delete. og så har vi i bundet et par tables (Lad os se på X) som refererer rundt til alle disse forskellige tables OG til A med en cascade på referencen til A. Nu er det sådan at alle de tables X referere til som referere til A, der peger (B,C,D,E,F osv tables der referere A) på en X... ned Not Null... og vi ville undersøge om det skaber nogle af de performance Issues vi har når vi sletter...

Se om du eventuelt kan bruge dette her til noget:
http://msdn.microsoft.com/en-us/magazine/cc164047.aspx

Så vidt jeg forstår det du skriver, så har i en en masse cirkulære referencer. Overvej om i har brug for referencerne fra X tabellerne til A. X tabellerne har jo reference til B,C,D,osv tabellerne, som har reference videre til A. Så det burde være muligt at gå fra X til A via B,C,D!

I kan jo midlertiddig prøve at fjerne constraints imellem X og A uden at fjerne nogen kolonner for at se om det løser jeres performance problem.

Fjerner man Cascade Delete Mellem A og X går tingene 10-20 gange hurtigere.
Fjerner man constrains sker der ikke nogen forbedring

Var derfor vi ville prøve det andet.

det er desvære ikke muligt at fjerne nogle af de sammenknytninger der er, dette skyldes at det ofte er vigtigt at vide hvilke X'er der er forbundet til hvilke A'er for at kunne frasortere på forskellige previliges, mens det ikke så ofte er interassant at kigge i B, C, D og E... kun når man ønsker at editere i et specifikt object... kunne nok forklares bedre, men ville kræve en længere stil...

Anyways kigger på linket i morgen... og tak for svar :)