Discussion :

[devgero75]

Bonjour,
Je crois que presque tout est dit dans l'intitulé

Dans Microsoft SQL Server Management Studio, si l'on fait un delete d'une ligne sur un table, on reçoit le message suivant: "(1 row(s) affected)" dans l'onglet "Messages"
Le problème est que si on a mis en place des "delete on cascade" et que des suppressions IMPLICITES sont effectuées dans les tables filles, on n'a aucune information...
C'est problématique car on peut faire un grand nombre de suppression sans s'en rendre compte.

Existe t-il une solution pour être informé du nombre réel de lignes supprimées ? et si possible dans quelles tables ?

Merci d'avance pour toute aide

[SQLpro]

Non et cela n'a aucun intérêt. Ces messages sont mêmes totalement cosmétiques car au niveau applicatifs ils ne sont généralement pas interprétés....

En revanche, rien de vous empêche de mettre en place vos propres routines de suppression pour savoir ce qui se passe avec au choix :

• la clause OUTPUT
• des déclencheurs
• une trace de modif (CHANGE TRACKING ou CHANGE DATA CAPTURE)

CONSEIL : enfin, le mode DELETE CASCADE, s'il est séduisant est assez dangereux, car peut vite entraîner des blocages, de la contention, voir des verrous mortels. Préférez les modes NO ACTION / SET NULL / SET DEFAULT

A +

[aieeeuuuuu]

CONSEIL : enfin, le mode DELETE CASCADE, s'il est séduisant est assez dangereux, car peut vite entraîner des blocages, de la contention, voir des verrous mortels. Préférez les modes NO ACTION / SET NULL / SET DEFAULT

Pire, il peux permettre à un utilisateur des actions pour lesquels il n'a pas les privilèges, si l'on n'y fait pas attention :

Prenons l'utilisateur SQL USR_CLI qui a les droits supprimer des clients, mais pas les commandes.
Ajoutez une suppression en cascade entre les clients et les commandes (en supposant que les deux tables aient le même propriétaire).
Lorsque USR_CLI supprimera un client, les commandes de ce client seront également supprimées.
Vous n'aurez plus qu'a aller expliquer à la compta, que le ON DELETE CASCADE, c'est pratique !

Donc oui, c'est pratique, mais à utiliser avec parcimonie, et en ayant bien conscience de toutes les conséquences qu'il pourra avoir.
Et quand je lis ça :

C'est problématique car on peut faire un grand nombre de suppression sans s'en rendre compte.

je me dis que vous en avez peut-être un peu abusé...

[devgero75]

Merci pour ces propositions que j'ai testées (ou essayé de tester). Mais je n'ai toujours pas de solution satisfaisante.

- cause OUTPUT: intéressant, permet de récupérer la ou les lignes supprimées, mais ne fonctionne pas sur les delete on cascade (à moins de d'utiliser des trigger, voir ligne ci-dessous)

- des déclencheurs : une alternative que je n'envisage pas pour l'instant, il faudrait juste remplacer 500 "delete on cascade" par un trigger "instead of delete", du boulot et surtout des risques d'erreurs

- une trace de modif (CHANGE TRACKING ou CHANGE DATA CAPTURE) : à priori ces fonctionnalités ne sont dispos qu'à partir de sql 208


Je suis bien d'accord avec vos conseils et remarques, mais je ne vais pas toucher comme ça à un code écrit il y a déjà plusieurs années
Je ne pense pas non plus abuser en disant "C'est problématique car on peut faire un grand nombre de suppression sans s'en rendre compte. " et c'est bien la raison pour laquelle je pose la question sur ce forum, suite à une opération de maintenance exceptionnelle qui a viré au drame.

Il faut bien comprendre qu'il n'y a pas ici que des développeurs qui travaillent sur les dernières technos ou qui écrivent des applications "from scratch".

[aieeeuuuuu]

Je ne pense pas non plus abuser en disant "C'est problématique car on peut faire un grand nombre de suppression sans s'en rendre compte. "

Relisez bien ma phrase :

je me dis que vous en avez peut-être un peu abusé...

Je ne dis pas que vous avez abusé en disant cela, je dis que vous (ou vos prédécesseurs) avez abusé du ON DELETE CASCADE pendant la conception de la BDD.