Par défaut, lorque qu'une "grosse" erreur se produit dans une procédure
stockée (de type violation de FOREIGN KEY, par exemple), ma procédure
s'arrête brutalement et l'erreur SQL lève une exception dans mon code .Net,
ce qui à priori est le fonctionnement normal d'ADO.Net.
Je cherche à implémenter une gestion manuelle des erreurs et transactions,
donc je voudrais que, d'une part, aucune exception ne soit levée par
l'erreur SQL, et que d'autre part, l'exécution de ma procédure stockée se
poursuive après l'apparation de ma violation de FOREIGN KEY, de telle sorte
que je puisse faire moi-même un ROLLBACK, et surtout, que je puisse renvoyer
un code d'erreur personnalisé.
Je suis donc à la recherche d'un moyen de "catcher" les erreurs de type
violation de FOREIGN KEY au sein du code T-SQL.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
DERDOUR
Try this:
UPDATE urTable SET urAttrinutes = urValues WHERE urConditions
IF @@ERROR = 547 --Error Foreign Key Violation RETURN urMessage
".:: Kall [SnX] ::." <kall.guquet(RemoveThis)@m6net.fr> a écrit dans le message de news:
Bonjour !
Je suis confronté au dilemne suivant :
Par défaut, lorque qu'une "grosse" erreur se produit dans une procédure stockée (de type violation de FOREIGN KEY, par exemple), ma procédure s'arrête brutalement et l'erreur SQL lève une exception dans mon code
.Net,
ce qui à priori est le fonctionnement normal d'ADO.Net.
Je cherche à implémenter une gestion manuelle des erreurs et transactions, donc je voudrais que, d'une part, aucune exception ne soit levée par l'erreur SQL, et que d'autre part, l'exécution de ma procédure stockée se poursuive après l'apparation de ma violation de FOREIGN KEY, de telle
sorte
que je puisse faire moi-même un ROLLBACK, et surtout, que je puisse
renvoyer
un code d'erreur personnalisé.
Je suis donc à la recherche d'un moyen de "catcher" les erreurs de type violation de FOREIGN KEY au sein du code T-SQL.
Quelqu'un aurait-il une méthode ???
Try this:
UPDATE urTable SET urAttrinutes = urValues
WHERE urConditions
IF @@ERROR = 547 --Error Foreign Key Violation
RETURN urMessage
".:: Kall [SnX] ::." <kall.guquet(RemoveThis)@m6net.fr> a écrit dans le
message de news:eCrN2860DHA.2396@TK2MSFTNGP09.phx.gbl...
Bonjour !
Je suis confronté au dilemne suivant :
Par défaut, lorque qu'une "grosse" erreur se produit dans une procédure
stockée (de type violation de FOREIGN KEY, par exemple), ma procédure
s'arrête brutalement et l'erreur SQL lève une exception dans mon code
.Net,
ce qui à priori est le fonctionnement normal d'ADO.Net.
Je cherche à implémenter une gestion manuelle des erreurs et transactions,
donc je voudrais que, d'une part, aucune exception ne soit levée par
l'erreur SQL, et que d'autre part, l'exécution de ma procédure stockée se
poursuive après l'apparation de ma violation de FOREIGN KEY, de telle
sorte
que je puisse faire moi-même un ROLLBACK, et surtout, que je puisse
renvoyer
un code d'erreur personnalisé.
Je suis donc à la recherche d'un moyen de "catcher" les erreurs de type
violation de FOREIGN KEY au sein du code T-SQL.
UPDATE urTable SET urAttrinutes = urValues WHERE urConditions
IF @@ERROR = 547 --Error Foreign Key Violation RETURN urMessage
".:: Kall [SnX] ::." <kall.guquet(RemoveThis)@m6net.fr> a écrit dans le message de news:
Bonjour !
Je suis confronté au dilemne suivant :
Par défaut, lorque qu'une "grosse" erreur se produit dans une procédure stockée (de type violation de FOREIGN KEY, par exemple), ma procédure s'arrête brutalement et l'erreur SQL lève une exception dans mon code
.Net,
ce qui à priori est le fonctionnement normal d'ADO.Net.
Je cherche à implémenter une gestion manuelle des erreurs et transactions, donc je voudrais que, d'une part, aucune exception ne soit levée par l'erreur SQL, et que d'autre part, l'exécution de ma procédure stockée se poursuive après l'apparation de ma violation de FOREIGN KEY, de telle
sorte
que je puisse faire moi-même un ROLLBACK, et surtout, que je puisse
renvoyer
un code d'erreur personnalisé.
Je suis donc à la recherche d'un moyen de "catcher" les erreurs de type violation de FOREIGN KEY au sein du code T-SQL.