[forms] pre-update

Version imprimable

15/09/2004, 12h20
plaineR

[forms] pre-update

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...) ?
15/09/2004, 12h25
orafrance

un POST dans le pre-update pourrait vous aider.

POST permet de synchoniser l'écran et la base sans faire le COMMIT ;)
15/09/2004, 12h30
plaineR

Sauf que le post n'est pas autorisé dans le pre-update, la phase de commit ayant déjà débuté...
15/09/2004, 12h32
orafrance

ha oui mince :?
15/09/2004, 12h33
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 :?
15/09/2004, 12h39
plaineR

Re: [forms] pre-update

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...
15/09/2004, 14h00
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.
15/09/2004, 14h07
plaineR

Citation:

Envoyé par 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.

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 ?
15/09/2004, 14h09
orafrance

Re: [forms] pre-update

Citation:

Envoyé par 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...

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 :?
15/09/2004, 14h12
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 ?
15/09/2004, 14h35
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".

Citation:

Envoyé par orafrance

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) ?
15/09/2004, 14h43
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 ?
15/09/2004, 14h52
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.
15/09/2004, 14h57
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
15/09/2004, 15h01
plaineR

Citation:

Envoyé par 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.

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)?
15/09/2004, 15h25
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.
15/09/2004, 15h43
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 :?
15/09/2004, 15h47
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...
15/09/2004, 16h03
plaineR

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

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...
15/09/2004, 16h03
orafrance

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

Edit : comme l'a proposé plainer :lol:
15/09/2004, 16h09
plaineR

Parce que si je ne commit pas mes modifications de mon bloc2 (en faisant un clear_block par exemple sur le bloc2), le champ du bloc1 est modifié alors qu'il ne devrait pas puisque j'ai annulé les modifications du bloc2...
Pour rappel: il ne doit être modifié uniquement si je modifie (au niveau de la base de données) un enregistrement du bloc2.

Aïe, j'commence à avoir mal à la tête avec ce problème, ce n'est pas si simple que cela en avait l'air au départ... :wink: