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 : 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
 
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.