Discussion :

[jbrasselet]

Bonjour,

je travaille actuellement sur SQL Server et je suis à la recherche de bonnes pratiques pour gérer les erreurs dans les procédures stockées.

Je sais qu'il y a l'utilisation par exemple de @@error suivi d'un GOTO. Mais il me semble que le GOTO ne soit pas spécialement approprié.

Avez-vous des normes dans vos projets? Si oui, de quels types?

Merci d'avance.

[SQLpro]

Je sais qu'il y a l'utilisation par exemple de @@error suivi d'un GOTO. Mais il me semble que le GOTO ne soit pas spécialement approprié.

Pour ma part je le trouve plus précis que le moderne TRY/CATCH introduit à partir de la version 2005.
En effet lorsque vous êtes dans le TRY/CATCH la seule indication que vous pouvez avoir sur l'endroit ou s'est produite l'erreur est le N° de la ligne de code. Pas vraiment utile notamment si l'on est en, SQL dynamique et si les développeur sont assez bourrin pour ne pas indenter leur code !

A +

[jbrasselet]

J'ai trouvé en faisant des recherches sur le try/catch les fonctions suivantes :
- ERROR_NUMBER()
- ERROR_SEVERITY()
- ERROR_STATE()
- ERROR_PROCEDURE()
- ERROR_LINE()
- ERROR_MESSAGE()

Est-ce que ça ne résoud pas le problème du manque d'info?

Je me renseigne aussi sur comment retourner un message d'erreur à l'application appelante.
Il y a par exemple la fonction RAISERROR, certains font des SELECT de la table sysmessage.

Qu'utilisez-vous de manière générale sur le sujet?

[SQLpro]

- ERROR_LINE() vous donne le n° de position ordinale de la ligne dans le code source... beurk !

Il y a par exemple la fonction RAISERROR

oui

certains font des SELECT de la table sysmessage.

beurk !
Il est possible de rajouter ses propres message d'erreur (n>50000) Mieux vaut faire cela. mais les messages par défaut sont en général assez explicites....

A +

[seminoque]

Personnellement, j'enregistre l'erreur dans une table et je renvoie le numéro d'erreur à l'application appelante, même si cette dernière n'en fait généralement pas grand chose et se contente d'afficher "désolé pour cette erreur etc..."

Voici ce que ça donne sur une procédure simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
CREATE PROCEDURE MA_PROC
AS
 DECLARE @Erreur INT
 SET @Erreur=0
 
 --Insérer ici l'ordre SQL
 
 SET @Erreur=@@error
 
 IF @Erreur != 0
  BEGIN
   DECLARE @Message NVARCHAR(50)
   SET @Message='ERREUR MA_PROC '+CAST(@Erreur AS VARCHAR(20))
   INSERT TABLE_ERREUR(getdate(), @Message)
 END
 
 RETURN @Erreur
GO

Voici un cas un peu plus compliqué avec annulation d'une transaction :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
 
CREATE PROCEDURE MA_PROC
AS
 DECLARE @Erreur INT
 SET @Erreur=0
 
 BEGIN TRAN
 
  --Premier ordre SQL
  SET @Erreur=@@error
  IF @Erreur!=0 GOTO FIN
 
  --Deuxième ordre SQL
  SET @Erreur=@@error
 
FIN:
 IF @@trancount>0
  BEGIN
   IF @Erreur != 0
    BEGIN
     ROLLBACK TRAN
     DECLARE @Message NVARCHAR(50)
     SET @Message='ERREUR MA_PROC '+CAST(@Erreur AS VARCHAR(20))
     INSERT TABLE_ERREUR(getdate(), @Message)
    END
   ELSE
    BEGIN
     COMMIT TRAN
    END
  END
 
 RETURN @Erreur
GO

Quant au try catch, je n'ai jamais essayé en SQL (je n'ai pas changé mes habitudes depuis SQL Server 6.5 ) mais je l'utilise en ASP .NET.

En espérant que cela t'aidera