Oracle : PL/SQL, problème tout con [SGBD/SQL] - SQL/NoSQL - Programmation
Marsh Posté le 28-03-2006 à 16:49:11
Arjuna a écrit : Oracle, c'est de la merde et c'est pas nouveau. |
Je dois me tapper un gros projet sous Oracle sous peu, tu lui reproches quoi exactement à cet environnement ?
Arjuna a écrit : |
Je trouve pas de trace de sigdep dans ton code, tu le récupères comment dans ces conditions
Marsh Posté le 28-03-2006 à 16:52:17
Arjuna a écrit : Oracle, c'est de la merde et c'est pas nouveau. |
belle manière de cacher son ignorance
Essaye :
Code :
|
Par ailleurs tu as MERGE qui remplace avantageusement ton update ou insert selon l'exception
Au pire :
Code :
|
le SELECT est alors inutile
Marsh Posté le 28-03-2006 à 16:54:20
à propos du MERGE : http://www.developpez.net/forums/v [...] p?t=386525
Marsh Posté le 28-03-2006 à 17:52:26
orafrance a écrit : belle manière de cacher son ignorance |
Je cache pas mon ignorance. Un SGBD qui utilise la locale du client dans un trigger, je trouve ça plus que douteux (et y'a pas que ça que je reproche à Oracle, ça encore ça peut avoir certains avantages).
Marsh Posté le 28-03-2006 à 17:58:56
Bon, sinon, j'ai à la fois trouvé où ça plantait (même pas dans le corps du trigger) et un moyen plus efficace pour squizzer le trigger (truc pas mal d'ailleurs, comme quoi Oracle c'est pas que de la merde).
J'ai débuggé le "when" (première ligne) de déclenchement tu trigger.
En fait, le filtre "codzn <> 3" correspond à mon cas (encore plus que le coup du new.sigdep = ' ', sauf qu'avec un OR avant et des parenthèses mal équilibrée, ça ne risquait pas de marcher.
Ensuite, ce qui plantait, c'est le :
nvl(old.codzn2, 0) <> new.codzn2
le crétin qui a pondu ça a juste oublié que ce champ est un varchar, et que si new.codzn2 = ' ' (mon cas) ben comparer 0 avec ' ' se traduit pas une erreur de type.
le when corrigé :
Code :
|
voilà.
Merci d'avoir pris la peine de regarder mon problème en tout cas
Sinon, pour le IF, j'avais bêtement mis un "end;" tout court, c'était ça mon problème, je hais le PL/SQL, et du coup j'évite autant que possible d'en faire - ça tombe bien foutre des trigger sur la base d'un ERP, y'a rien de mieux pour le planter, donc on me demande as d'en faire -
Pour le MERGE, je me trompe peut-être, mais là je suis sur 8i, et je ne crois pas que ce soit supporté, si ? En tout cas, si ça l'est, je garde sous le coude, c'est vrai que c'est moins chiant.
Marsh Posté le 29-03-2006 à 11:36:20
Arjuna a écrit : Je cache pas mon ignorance. Un SGBD qui utilise la locale du client dans un trigger, je trouve ça plus que douteux (et y'a pas que ça que je reproche à Oracle, ça encore ça peut avoir certains avantages). |
Et si tu veux que le trigger régisse différemment selon le contexte ??? Genre remplir un champ LAST_UPDATED_BY
Marsh Posté le 29-03-2006 à 11:38:44
Arjuna a écrit : |
je crois bien que tu as raison
Marsh Posté le 28-03-2006 à 16:04:37
Oracle, c'est de la merde et c'est pas nouveau.
Le "to_number" se localise comme un con à partir de la locale du client, et du coup j'ai un trigger mal codé qui plante.
J'ai pas envie de le foutre en l'air, donc je veux juste faire la modif bidon qui va me permettre de le squizer.
Dans ma requête, dans mon cas précis, j'ai "SIGDEP" qui est vide ( :new.sigdep = ' ' ).
Hors, applicativement, c'est impossible, donc je suis certain que seul "moi" pourrai faire cette requête (un peu compliqué à expliquer, mais c'est ce qu'il y a de plus propre à faire, mise à part corriger le trigger, mais j'ai pas envie de me plonger dedans)
Du coup, je voudrais simplement faire un test sur le trigger : si sigdep != ' ', alors je fais tout le bordel, sinon je zappe.
Sauf que la syntaxe PL/SQL est un gros mystère pour moi, et je m'en sors pas. Je suis sur le serveur de production, et du coup à chaque test, je vous tous les utilisateurs dans les choux. Ca me lourde.
Est-ce que qq1 peut me dire quoi rajouter ?
Merci
Message édité par Arjuna le 28-03-2006 à 16:05:54