Trigger et raise_application_error : comment forcer le "plantage" ?

[StringBuilder]

Bonjour,

Je travaille avec un ERP.
Je n'ai pas la source du programme, et il ne peut pas être modifié.
=> Je ne sais donc pas comment il gère les erreurs, et il m'est impossible d'obtenir l'information ou une modification à ce niveau.

Il manque un contrôle lors d'une modification dans la base.

La garantie que j'ai, c'est que tous les traitements de l'ERP sont transactionnels, et le fait de planter durant une requête provoquera un rollback de l'intégralité du traitement.

Voici mon trigger :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
CREATE OR REPLACE
TRIGGER wtrig_esk
-------------------------------------------------------------------------------
--      Trigger : wtrig_esk
--      Fichier : ap$triggers:wtrig_esk.sql
--      Lorsque code emplacement vide et NEW.C01 < 0, alors provoquer
--      une exception.
-------------------------------------------------------------------------------
--      Auteur    : S.Devidal
--      Version   |Date         |Auteur  |Objet
-------------------------------------------------------------------------------
--      V.1       |08/02/2012   |DES     |Création du trigger
-------------------------------------------------------------------------------
BEFORE UPDATE
ON esk
FOR EACH ROW
WHEN (NEW.codsoc = 218 AND NEW.codemp = ' ' AND NEW.c01 < 0)
DECLARE
  bidon integer;
BEGIN
   raise_application_error(-20001, 'Pas dispo dans l''emplacement générique (' || to_char(:OLD.c01) || ')');
   bidon := 1/0;
END;

Sans la variable "bidon", aucun problème depuis SQL Developpeur. Un update sur ESK qui entre dans le test du trigger provoque bel et bien une erreur, et la mise à jour échoue.

En revanche, depuis l'ERP, aucune erreur n'est levée, et l'instruction passe bien.

J'ai donc été obligé de rajouter la variable "bidon" afin de faire une division par 0, et planter pour de bon.

Ca marche, l'ERP détecte l'erreur, et aucune mise à jour n'est faite.

Sauf que plus crade, tu meurs.

Avec SQL Server, je sais que selon les numéros d'erreurs et autres paramètres passés au RAISEERROR, on peut produire différents niveaux d'erreur (du simple message informatif à la destruction immédiate de la connexion).

Est-ce qu'avec Oracle, je peux reproduire ça ? Lorsque je fait mon raise_application_error, je souhaite que le programme s'arrête immédiatement, exactement comme lorsqu'on fait une division par 0.

[Waldar]

Essayez avec RAISE tout court :
http://docs.oracle.com/cd/B19306_01/..._statement.htm

[skuatamad]

Ou essaie avec d'autres numéros d'erreur, peut être que -20001 (le plus classique) est déjà catché par l'ERP.
La section de gestion des erreurs

DBMS_STANDARD.raise_application_error(numero_erreur, message[, {TRUE | FALSE}])

numero_erreur représente un entier négatif compris entre -20000 et -20999
message représente le texte du message d'une longueur maximum de 2048 octets
TRUE indique que l'erreur est ajoutée à la pile des erreurs précedentes
FALSE indique que l'erreur remplace toutes les erreurs précédentes

[Scriuiw]

Ou déclare ta propre execption dans ton trigger

Code :

1
2
 
EXC_MON_ERREUR_A_MOI  EXCEPTION;

Puis tu l'appelles

Code :

1
2
 
RAISE EXC_MON_ERREUR_A_MOI;

Ce serait étonnant que l'ERP puisse l'intercepter