Delete On Cascade

Delete On Cascade - SQL/NoSQL - Programmation

Marsh Posté le 18-04-2008 à 15:42:38    

Bonjour tout le monde,
 
Je suis en train de faire une petite application en php pour ajouter/supprimer/modifier des personnes dans une table d'une bd.
Mais il y a une contrainte de référence entre deux tables et lorsque je souhaite supprimer une personne, j'ai le message d'erreur suivant qui apparaît:

Code :
  1. Warning: odbc_exec() [function.odbc-exec]: SQL error: [Microsoft][ODBC SQL Server Driver][SQL Server]The DELETE statement conflicted with the REFERENCE constraint "FK_PersonHasRole_Person". The conflict occurred in database "ICTnet", table "dbo.PersonHasRole", column 'personId'., SQL state 23000 in SQLExecDirect in


Je dois donc faire un DELETE ON CASCADE puor que ça fonctionne mais pour cela, il faut qu'en premier lieu je modifie ma table, non?
Et comment je fais cette modification?
 
Merci pour votre aide  :)

Reply

Marsh Posté le 18-04-2008 à 15:42:38   

Reply

Marsh Posté le 18-04-2008 à 19:34:34    

je ne connais pas SQL server, mais pourquoi veux tu modifier ta table ? le DELETE ON CASCADE s'applique à ta clé étrangère.
 
Par contre en supprimant une personne, tu effaceras en cascade tous les enregistrements qui se réfère à celui-ci via ta contrainte.
 
Il existe d'autres mode de fonctionnements, et tu aura peut-être besoin de la version UPDATE ON CASCADE, sauf si tu ne touches jamais au champ ciblé par ta clé étrangère lors de tes modifications.
 
Pour mettre en place le DELETE ON CASCADE, il faut de mémoire faire un ALTER sur ta contrainte FK, regarde la syntaxe pour SQL server. Mais à priori tu n'as aucune modification à faire sur ta table.

Reply

Marsh Posté le 18-04-2008 à 20:07:22    

par expérience interposée (j'ai jamais eu de problèmes, mais les histoires de mes collègues m'ont convaincu), je déconseille fortement d'utiliser la moindre fonctionnalité "cascade", que ce soit pour de l'update ou de l'insert.
 
en effet, une seconde d'inatention, et tu peux te retrouver avec une base de données complètement vierge, c'est pas terrible quand ça t'arrive en production.
 
autre souci, le rollback segment qui explose car trop de lignes sont liées.
ou la stack de récursivité car tu as trop de références dans tous les sens.
 
bref, le cascade est à la fois dangereux et peu fiable.
 
il vaut mieux y aller pépère tranquille, et faire à la main table par table en suivant le cheminement inverse du cascade.
 
c'est long et chiant, mais ça sauve la vie.
 
autre élément important je pense : généralement, à des fins d'historique, il vaut mieux "désactiver" un enregistrement plutôt que de le détruire. un petit champ "status" dans les tables principales, ça mange pas de pain, et ça rend de grands services.

Reply

Marsh Posté le 21-04-2008 à 08:27:12    

Ok, alors je viens de lire attentivement vos réponses.  
 
Je suis d'accord avec le fait que c'est dangereux le CASCADE donc je vais essayer de l'effectuer comme le propose MagicBuzz, soit à la main, table après table en suivant le cheminement inverse du CASCADE ou, il faut que je réfléchisse, soit en désctivant l'enregistrement...
 
Je vais regarder cela mais je vous remercie déjà pour vos réponses données qui plus est, un vendredi soir!  :)

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed