Discussion :

[NarbOni]

Bonjour à tous,

j'ai actuellement une base sous Sybase composée de procédures stockées.
Je souhaite migrer ma base Sybase vers Oracle néanmoins je souhaitais savoir comment les erreurs vont être traitées ?

Je vous met ci dessous une de mes nombreuses procédures stockées.

Code sql :

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
create procedure proc_validate_ident   
as    
 
declare @ERREUR int   
 
 
delete IDENTIFICATION FROM TEMPIDENT , IDENTIFICATION   
where TEMPIDENT.TEMPIDENT_IDENT = IDENTIFICATION.IDENT_IDENT   
 
select @ERREUR = @@ERROR   
 
IF (@ERREUR = 0)   
begin   
  INSERT IDENTIFICATION (IDENT_IDENT,IDENT_GENRE,IDENT_NOM,IDENT_ADR1,IDENT_ADR2,   
  IDENT_ADR3,IDENT_ADR4,IDENT_CIGAP,IDENT_NUMSS,IDENT_DATEMOUV)   
  SELECT TEMPIDENT_IDENT,TEMPIDENT_GENRE,TEMPIDENT_NOM,TEMPIDENT_ADR1,TEMPIDENT_ADR2,   
  TEMPIDENT_ADR3,TEMPIDENT_ADR4,TEMPIDENT_CIGAP,TEMPIDENT_NUMSS,TEMPIDENT_DATEMOUV   
  FROM TEMPIDENT   
 
end   
else   
begin   
    print "Probleme avec la table IDENTIFICATION "   
    return   
end

Par exemple, je n'ai aucune idée dont va être traité ma ligne :

" select @ERREUR = @@ERROR " sous entendu le @@ERROR retourne un code erreur, ce qui m'intéresse ici, c'est le cas ou il n'y a pas d'erreur, le cas ou il retourne 0 en clair.

Je souhaiterais avoir de l'aide ou de la doc pour avancer dans mon projet de migration..

Merci à tous,

NarbOni

[mnitu]

Oracle != Sysbase.
Vous devez réécrire vos procédures en PL/SQL. Il y a un tutoriel PL/SQL sur ce site.

[NarbOni]

Oui jusque là j'avais compris, il va falloir réécrire pour passer de Transact-SQL à Pl/Sql, néanmoins, ça ne m'explique pas de tout comment gérer les erreurs en Pl/Sql ... ? Comparé au retour erreur en Transact-SQL.

[mnitu]

Bah c’est plus compliqué que ça en réalité.
Pour moi votre procédure devient

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
 
CREATE procedure proc_validate_ident   
AS       
Begin
  Delete IDENTIFICATION
  Where Exists (Select Null
                  From TEMPIDENT
                 Where  TEMPIDENT.TEMPIDENT_IDENT = IDENTIFICATION.IDENT_IDENT
  --  
  INSERT IDENTIFICATION (IDENT_IDENT,IDENT_GENRE,IDENT_NOM,IDENT_ADR1,IDENT_ADR2,   
                         IDENT_ADR3,IDENT_ADR4,IDENT_CIGAP,IDENT_NUMSS,IDENT_DATEMOUV)   
  SELECT TEMPIDENT_IDENT,TEMPIDENT_GENRE,TEMPIDENT_NOM,TEMPIDENT_ADR1,TEMPIDENT_ADR2,   
         TEMPIDENT_ADR3,TEMPIDENT_ADR4,TEMPIDENT_CIGAP,TEMPIDENT_NUMSS,TEMPIDENT_DATEMOUV   
  FROM TEMPIDENT ;
End;       
/

Et comme vous pouvez le constaté je ne ressens le moindre besoin d’ajouter un gestionnaire des exceptions en cas d’anomalie.
Mais est-ce que j'ai bien compris votre code Transact SQL (c'es un langage que je ne maîtrise pas) ?

[NarbOni]

En fait, nous faisons une suppression et dans le SELECT on y indique un code erreur ( Nous avons 0 si la suppression de la table s'est déroulée correctement et un autre chiffre peut importe le nombre vu que ce n'est pas correct ).

Si la suppression s'est correctement déroulée on procède à la création et insertion, sinon, nous avons un message nous annonçant que nous avons eu un problème lors de la suppression.

Ce que je souhaitais savoir c'est si nous avions la possibilité de gérer ce 'code retour' afin de savoir si la suppression s'exécute comme il faut, et si ce n'est pas le cas, m'avertir du problème ?

Encore merci,
NarbOni.

[mnitu]

C'est une autre philosophie avec Oracle. Vous supprimez les donnés via delete. Si une erreur se produit alors une exception sera levée et l'insertion ne va pas poursuivre. Sinon la procédure continue avec l'insertion. C'est le code que j'ai vous aie proposé.

Maintenant, le code de retour ne sert à rien. Si une exception est levée, par le delete ou par l'insert, comme elle n'est pas intercepté par la procédure elle est envoyé automatiquement au code appelant. C'est peut être à ce code appelant d'intercepter l'exception et de la traiter.