2010-03-15 11 views
1

J'écris une procédure stockée dans laquelle j'utilise try catch block.Est-il possible d'élever l'exception du système pour attraper l'exception manuellement?

Maintenant, j'ai une colonne unique dans un tableau. Lorsque je tente d'insérer valeur en double, il émet une exception à l'exception aucune 2627.

Je veux que ce soit fait comme ce

si (exists (select * from tblABC où la 'valeur' ​​col1 =) = true) raiseError (2627) - raise erreur système qui aurait jeté si je l'aurais utilisé requête d'insertion pour insérer valeur en double

EDIT:

Je suis en utilisant la transaction qui obtient rollback sur la gestion des exceptions donc conduisant à incrémenter de @@ Valeur d'identité obtenue ecuted dans les requêtes précédentes b4 l'exception s'est produite.

Je veux vérifier toutes ces exceptions qui pourraient se produire b4 effectivement l'insertion. Pour ce faire, je vérifierais l'exception qui pourrait déclencher une erreur manuellement en utilisant l'instruction select avec if else. Ici, je vais pouvoir attraper violation de clé unique, mais dérogation ne produit donc je jetterons exception délibérément ici, mais cette exception que je veux devrait être une exception système par exemple d'erreur 2627

et la méthode qui sera mieux, en utilisant insérer une requête ou en recherchant la valeur en double avant l'insertion en utilisant la requête Select ?

EST-IL POSSIBLE DE LEVER DU SYSTÈME importe comment EXCEPTION CAPTURE EXCEPTION MANUELLEMENT i.e. LANCER MÊME QUE SQL EXCEPTION AURAIT LANCÉ

Répondre

2

Vous ne pouvez pas augmenter les erreurs de système. RAISERROR (2627 ...) est illégal. Mis à part le fait que vous êtes en train de mentir (aucune erreur 2627 ne s'est produite), il vous manque les insertions dans le format du message. L'application ne devrait jamais compter sur la continuité d'IDENTITY, le fait que vous vous plaigniez qu'elle «augmente l'auto-incrément» ravit votre application a un bug (dans la conception à coup sûr, sinon dans le code). Les valeurs IDENTITY peuvent contenir des lacunes, fait partie de leurs spécifications. Pour ce qui est mieux, pour insérer et attraper, ou pour essayer de mettre à jour: cela dépend de votre modèle prédominant. Si la valeur est susceptible d'exister, la première stratégie UPDATE est meilleure. Si la valeur est susceptible de ne pas exister ou si la probabilité est inconnue il est préférable d'INSÉRER et d'attraper l'erreur, pour des raisons de performance et, plus important encore, d'exactitude (la vérification SELECT n'est jamais correcte sous la concurrence).

+0

@Remus Plz répondre pour mon édition. sry pour ne pas avoir d'informations descriptives sur mon Ques –

+0

Après votre modification, mon message n'a besoin d'aucune mise à jour. Tout est là. –

+0

Il n'y a pas de sémantique de relance dans TRY/CATCH de T-SQL. Vous devez lancer une exception * new *, de type personnalisé (ie code d'erreur supérieur à 50000). C'est désordonné, mais c'est l'état de l'art dans la gestion des exceptions T-SQL. –