Discussion :

[cosmos38240]

Bonjour,

Je voudrais pouvoir changer de manière dynamique mon record group associé à une LOV lors d'un interrogation (mode query)

Le when validate item ne fonctionne pas en mode query il me reste donc le when new item instance mais bon j'aimerai modifier mon RG uniquement lorsque je modifie la valeur d'un champ en mode query ...

Merci pour votre aide

[Aeternus]

La valeur du champ que tu modifie fait elle partie de la query de la LOV? Est ce une des conditions WHERE par exemple?

Ou s'agit il d'une toute autre query?

[cosmos38240]

Oui en effet le champ en question fait bien partie du where de la lov :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
where d.des_rentity = 'UCOD' 
AND cte_code = :b1.evt_class
AND cte_org = NVL(:b1.evt_class_org, CTE_ORG)
...

Mais par contre pour l'autre RG le champ n'est pas présent je ne peux créer la même requette c'est pour cela que je passe pas deux RG différents

[Aeternus]

en général pour les "options" dans les where j'utilise le truc suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

where (table.colonne = :block.variable OR :block.variable IS NULL)

Ce qui fait que seulement si le champ est rempli cela utilise la clause where sinon ca affiche tout en passant cette clause là...

Pour l'autre problème le RG doit quand meme renvoyer les memes champs pour remplir la lov sinon tu vas avoir un probleme de compatibilité entre la lov et le RG

[cosmos38240]

En effet la solution habituelle est de faire un NVL(champ, valeurdef);
Mais dans mon cas je ne veux pas de cela car les tables sont différentes.

D'autre part les rg ramnènent les données sans problème de compatibilité car cest les mêmes en tête j'avais bien fait attention

Je vais me resoudre à mettre un code de le when new item instance même si cela ne sera pas optimisé ...

[Aeternus]

Et avec le Key-next-item comme trigger ca marche pas mieux? (Bon evidemment faut forcer les gens a utiliser la touche next-item...

[plaineR]

Et avec le Key-next-item comme trigger ca marche pas mieux? (Bon evidemment faut forcer les gens a utiliser la touche next-item...

Le key-next-item se déclenche même si l'utilisateur n'a pas modifié le champ

Ce que tu peux faire c'est stocker l'ancienne valeur de ton champ dans une variable dans le trigger pre-text-item par exemple et sur le post-text-item tester que la nouvelle valeur est différente de l'ancienne (ce qui revient à faire un when-validate-item )

[Aeternus]

Ha? Je pensais que le when-validate-item se declenchait tjs quand on sortait du champ, meme si on n'en modifiait pas la valeur...



Sinon, une idée : je me disais que si la requete du RG dependait d'une valeur de son champ variable et qu'il devait choisir le RG a utiliser suivant cette variable, il pourrait faire un trigger KEY-LISTVAL sur le champ qui appelle la LOV et dedans définir les propriétés de sa LOV avec un test avant d'appeller la LOV proprement dites... non?

[cosmos38240]

Que ce soit en when-validate-item ou post-text-item il ne se declenche pas en mode query ...

C'est bien la tout mon problème

[cosmos38240]

La technique du key-listval marche !!!! Merciiiiiiiiiiii

En effet ce trigger est bien déclencher dans tous les cas en mode query ce qui me permet de manipuler le rg en dynamique thxxxx

[Aeternus]

Cool

[orafrance]

Ha? Je pensais que le when-validate-item se declenchait tjs quand on sortait du champ, meme si on n'en modifiait pas la valeur...

Comme quoi Forms est malin, il sait qu'il n'a pas à vérifier la validité d'une donnée qui n'a pas changée