Quel est le meilleur moyen de renvoyer une erreur à un processus TSQL?

Question

Voici le scénario:

1. Vous chargez une page, ce qui rend sur la base des données contenues dans la base de données (appeler ces les « hypothèses »)
2. Quelqu'un change les hypothèses
3. Vous soumettez votre page
4. ERREUR!

Le schéma général pour résoudre ce problème est le suivant (à droite?):

Dans votre sauvegarde proc, dans un début et validation de la transaction, vous validez d'abord vos hypothèses. Si l'un d'entre eux a changé, vous devriez retourner un message d'erreur gracieux, quelque chose comme une liste XML de l'ID avec lequel vous avez des problèmes, que vous gérez dans la page plutôt que de le laisser manipuler par l'infrastructure de gestion des erreurs par défaut.

Donc, ma question est quelle est la meilleure façon de faire cela?

• Renvoyer la liste xml et un indicateur d'erreur dans les paramètres out qui sont unset et 0 si elle se termine correctement?
• Utilisez un paramètre out pour renvoyer un état d'erreur et le résultat de la proc est soit la liste d'erreurs, soit les résultats valides du proc?
• Quelque chose d'autre? (Je dois souligner que RaiseError causerait le proc être dans l'erreur, et sont repris par le code de gestion des erreurs par défaut)

Mise à jour: Je voudrais revenir une liste maniplatable des ID qui ont échoué (Je prévois de mettre en évidence ces cellules dans l'application). Je pourrais les retourner au format CSV dans RAISEERROR, mais cela semble sale.

Answer 1

Utilisez la fonction RAISERROR avec la sévérité et/ou le niveau d'attente approprié. Si vous utilisez une gravité faible cela ne provoque pas nécessairement une exception, comme vous le prétendez, et avec .Net au moins c'est assez simple de récupérer ces messages. Le seul inconvénient est qu'avec la commande StoredProcedure, les messages .Net ne sont pompés que par groupes de 50.

Les procédures stockées peuvent renvoyer plusieurs ensembles de résultats. En fonction de votre mise à jour, vous pouvez également insérer des ID erronés dans une table temporaire, puis, à la fin de votre procédure, sélectionner les enregistrements de cette table en tant que jeu de résultats supplémentaire que vous pouvez consulter.

Answer 2

Je ferais un paramètre de sortie avec un message, le retour aura déjà quelque chose qui est différent de 0 s'il y a une erreur

aussi faire attention avec la transaction condamnée et vérifier avec xact_error, voir Use XACT_ABORT to roll back non trapable error transactions

Answer 3

Je suis d'accord - J'aime RAISEERROR:

-- Validate @whatever 
IF @whatever >= '5' 
BEGIN 
    RAISERROR ('Invalid value for @whatever - expected a value less than 5, but received %s.', 10, 1, @whatever) 
    RETURN 50000 
END;