Discussion :

[plaineR]

Environnement : form6i (patch9), oracle 8i

J'ai deux blocs : bloc1 et bloc2 (placé dans cet ordre dans le navigateur de forms).

Dans le pre-update de bloc2, je mets à jour un champ de bloc1.

Je modifie bloc2, je commit : le pre-update de bloc2 se déclenche.
Je retourne sur bloc1, à l'affichage mon champ de bloc1 a été modifié, mais à l'affichage seulement . Si je fais un query, je retrouve la valeur précédent de ce champ...

Maintenant, je modifie l'ordre de mes blocs dans le navigateur de forms (bloc2 passe avant bloc 1). Je refais la manipulation précédente. Et là miracle, la modification a été prise en compte à l'affichage et dans la base !

1. Avez-vous une explication à cela (j'ai bien une petite idée...) ?

2. Avez-vous une solution pour contourner ce problème SANS CHANGER l'ordre des blocs (cela me semble trop risqué, quelqu'un peut passer derrière moi et modifier l'ordre...) ?

[orafrance]

un POST dans le pre-update pourrait vous aider.

POST permet de synchoniser l'écran et la base sans faire le COMMIT

[plaineR]

Sauf que le post n'est pas autorisé dans le pre-update, la phase de commit ayant déjà débuté...

[orafrance]

ha oui mince

[orafrance]

ceci étant, c'est le fonctionnement normal de forms... si tu fais un query tu recharges les données de la base, il faut sauvegarder avant le query pour voir la modif

[plaineR]

Justement je commit !!!!

Le problème c'est que les modifications concernant mon bloc1 apportées dans le pre-update de mon bloc2 ne sont pas prise en compte au niveau de la base...

[SheikYerbouti]

Cela me parait normal. Les triggers se déclenchent dans l'ordre des blocs.
Le pre-update du bloc 1 s'exécute, puis celui du bloc2 qui modifie bloc1, mais trop tard !
ou alors il faudrait un deuxième commit.

[plaineR]

Cela me parait normal. Les triggers se déclenchent dans l'ordre des blocs.
Le pre-update du bloc 1 s'exécute, puis celui du bloc2 qui modifie bloc1, mais trop tard !
ou alors il faudrait un deuxième commit.

C'est ce que je pensais... La solution que j'ai choisi d'adopter :
1. dans le pre-update de mon bloc2, je renseigne un flag à 1
2. dans le key-commit :
- je commit une première fois
- si mon flag = 1 :
- j'attribue la valeur à mon bloc1
- je re-commit
- je repasse la valeur du flag à 0
C'est un peu lourd , mais cela à l'avantage de fonctionner quelque soit l'ordre du bloc. Qu'en pensez-vous ?

[orafrance]

Justement je commit !!!!

Le problème c'est que les modifications concernant mon bloc1 apportées dans le pre-update de mon bloc2 ne sont pas prise en compte au niveau de la base...

ha OK... bon bah là mais souvenir de Forms sont trop vague pour que je te sois très utile

Ta solution me semble bien complexe pour un soucis aussi simple

[SheikYerbouti]

N'existe t-il pas d'autre solution que celle passant par le trigger PRE-UDPDATE

Voir si le trigger POST-UPDATE ne se déclanche pas après tous les triggers PRE-UPDATE ?

[plaineR]

Le résultat est le même en passant par le post-update

Car à mon avis une fois qu'il a traité un bloc, il ne revient plus dessus. Ce qui est bizarre c'est que le statut de mon block1 passe à CHANGED dans le pre-update, puis repasse à QUERY après le commit_form, alors que dans la base la valeur n'a pas été changé.

De plus, quand je reviens sur mon block1 que je veux faire une modification dessus, j'ai un message "L'enregistrement a été modifié par un autre utilisateur".

Ta solution me semble bien complexe pour un soucis aussi simple

Oui, c'est ce que je trouve aussi... Une autre solution (plus simple) serait de changer la valeur de mon champ du block1 dans le when-validate-record, mais n'y a-t-il pas un risque dans ce cas que la valeur du bloc1 se trouve changée sans avoir modifié le bloc2 (ou vice-versa) ?

[orafrance]

mais t'es sûr que c'est bien un champ basé dans le bloc 1 ?

Il y a une relation maitre/détail entre les blocs ?

[SheikYerbouti]

Le commit_form remet tous les status a QUERY, vu que tous les changements ont été enregistrés en base.
Le problème est que tu modifie une donnée d'un bloc après que Forms ait passé les triggers d'update.

[plaineR]

Oui c'est un champs basé. Oui il y a une relation maitre-détail entre le bloc1 (maitre) et le bloc2 (détail).

Fonctionnellement ce que je veux faire (en simplifiant):
- mon bloc2 a un statut qui peut-être : Valide, en erreur ou à contrôler
- mon bloc1 a un statut qui peut-être : Valide (si tous les enregistrements
de mon bloc2 ont le statut valide) ou à contrôler (sinon)

=> Si je modifie une information d'un enregistrement du bloc2, le statut de cet enregistrement devient à controler. L'enregistrement du bloc1 doit donc lui aussi avoir le statut à contrôler

[plaineR]

Le commit_form remet tous les status a QUERY, vu que tous les changements ont été enregistrés en base.
Le problème est que tu modifie une donnée d'un bloc après que Forms ait passé les triggers d'update.

Oui c'est ce que je pense.

Que penses-tu de gérer cela sur le When-Validate-Record (à condition de tester le :system.record_status)?

[SheikYerbouti]

Qu'est-ce qui t'empêche de modifier le champs du bloc1 lorsque tu modifie celui du bloc2 ?

sinon tu remplace les triggers PRE-UPDATE par ON-UPDATE et tu gère à la main l'ordre de mise à jour.

[plaineR]

Qu'entends tu par "à la main" ? Passer une commande update ? Je peux également le faire sur le pre-update, mais après se pose le problème du raffraichissement de l'affichage (perf...)

Ensuite je ne modifie pas qu'un champs dans mon bloc2, mais il faut que lorsque le bloc2 a été modifié, mes 2 statuts (bloc1 et bloc2) passent à controler.

Le problème est que si je fais ça sur le when-validate-item (ou le when-validate-record, je viens de m'en rendre compte), lorsque je retourne sur mon premier écran sans avoir committer mes changements sur le deuxième, le statut du bloc1 a changé, alors qu'il ne devrait pas puisque je n'ai finalement pas committer les modifications apportées au bloc2...

Je ne vois pas finalement pas d'autres solutions qu'un double commit (cf. la première solution que j'avais proposée). C'est la seule qui revient à faire ce que je voulais faire initialement. Mais cela sent un peu l'usine à gaz

[SheikYerbouti]

Ou alors faire un traitement appelé dans le trigger KEY-COMMIT, pour mettre à jour tous tes champs dans les blocks avant d'appeler le commit_form...

[plaineR]

Merci à vous deux pour vos réponses, je clos le sujet puisqu'elles m'ont permis d'avancer.

Pour information, après reflexion, comme suggéré par SheikYerbouti, je pense opter pour une commande update qui met à jour la table associée au bloc1 dans le pre-update du bloc2, et lorsque je reviens au premier écran (bloc1) je raffraichis l'affichage via un execute_query...

Je vais faire des tests sur la base de prod, si cela s'avère trop gourmand en perf, j'opterai sans doute pour mon système de flag, plus bancal certes, mais moins gourmand en perf, puisque ne se pose pas le problème du raffraichissement de l'affichage...

[orafrance]

Bah pourquoi ne pas changer le bloc1 sur WHEN_VALIDATE_RECORD de bloc2 ?

Edit : comme l'a proposé plainer