Discussion :

[danbreizh]

Bonjour,

Je ne sais que faire...

J'ai une colonne xx dans une table
type numeric 10,2
valeur par defaut 20.00
non null
(pas de trigger actif)

Lorsque j'ouvre la table avec toutes ces colonnes, les champs de la colonne xx restent à 0.00.
Je ne comprends pas pourquoi. Si vous pouviez m'expliquer où est ma boulette...
Merci bien,
Daniel

[Waldar]

Les valeurs par défaut sont appliquées au moment de l'insertion : elle se substitue à une absence de valeur.
Mais si quand vous insérez une ligne vous indiquez une valeur, celle-ci est bien utilisée.

Le test ci-après est sous Oracle - ce sera pareil sur PG :

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
create table titi (c1 number(10,2) not null, c2 number(10,2) default 20 not null);
-- table TITI créé(e).
 
insert into titi (c1, c2) values (1, 5);
-- 1 lignes inséré.
 
insert into titi (c1, c2) values (2, null);
-- ORA-01400: impossible d'insérer NULL dans TITI.C2
 
insert into titi (c1) values (3);
-- 1 lignes inséré.
 
select c1, c2 from titi;
 
        C1         C2
---------- ----------
         1          5 
         3         20

[danbreizh]

Bonjour,

Merci de l'explication, je ne savais vraiment pas que cela fonctionnait comme cela, mais pour être sûr d'avoir compris, il donc faut que j'utilise ma table/colonne pour "initialiser" la valeur par défaut , c'est bien ça ?

MAIS... avec un trigger c'est PAREIL ?
Alors si je lance une fonction + trigger sur cette table/colonne par défaut, le trigger devrait donc également activer la valeur par défaut et la remplacer par son propre résultat?
Pourtant ça ne marche pas.. est ce que le trigger "active" aussi la table ? ce qui fait qu'à priori, le trigger va modifier la valeur par défaut en l'écrasant par une autre donnée calculée?
C'est comme ça que ça marche ou les triggers n'ont pas le même effet sur la table ..

Parce que si ça marche pas, alors c'est que c'est mon trigger qui n'est pas bon...

Merci encore
Dan

[Waldar]

N'hésitez pas à fournir le code du déclencheur, on devrait voir rapidement s'il force une valeur dans la colonne ou pas.

[danbreizh]

Bonjour,

J'avais abandonné l'orientation de calcul par trigger puisque cela ne fonctionnait pas.
Je m'étais retourné vers un script de calcul (struts/tag) hors postgres

La situation
TableA (donnéeA déjà enregistrée en BD lors du paramétrage de l'application)
TableB (saisie et enregistrement d'une donnée B via une IHM/ popup formulaire)
TableC = 0.00 par défaut ( Affichage du résultat instantané calcul A X B dans le formulaire, >> enregistrement du calcul dans table C)

Là aussi j'ai un problème, je ne m'en sort pas, je n'arrive même pas à afficher la donnée donnée A dans mon JSP STRUTS > > IHM, pourtant je crois que mes fichiers create, form, jpa, xml, tag, .. sont corrects ? je vais chercher la réponse sur l'espace forum/struts

Je vais pas m'en sortir.. je pars dans tout les sens.

N'étant pas sur d'être clair dans mes explications, vous trouverez une petite synthèse :

Solution 1 POSTGRESQL: utiliser un trigger pour mettre à jour la tableC dans postgresql
>> déclenchement du trigger par saisie de la donnée B (?) dans le formulaire, mais celle-ci n'est enregistrée en BD qu’après la validation du formulaire
Cette solution me pose problème, le trigger ne peut à priori que s'activer sur un événement en Bd, et en ce cas l’événement ( enregistrement donnée B) n'a lieu au moment de la validation du formulaire, donc après le calcul de la donnée C qui doit être déclenchée avant la validation finale, je tourne en rond. OU ALORS déclencher le trigger PSQL en JS dés la saie de la donnée B mais je ne sais pas si c'est possible ??

Solution 2 JS/STRUTS/: utiliser un script hors postgres pour faire le calcul, afficher instantanément son résultat dans le popup avec struts avant validation du formulaire ( enregistrement du calcul en Table C à la validation finale du formulaire)

Solution 3 .. ? peut être (certainement) qu'il y en a d'autres que je connais pas.

Pour ma part je pense que travailler en trigger directement sur postgres serait préférable et puis je suis sur un forum postgresql.

Si vous voulez bien, pouvez m'indiquer qu'elle est la meilleure solution que vous me conseilleriez pour que je ne m'éparpille pas et travaille que seulement sur l'une d'entr'elle.
Par rapport à cela je vous indiquerez mes codes;
Merci beaucoup de votre aide
Dan