Discussion :

[Magnus]

Hello,

Sous forms 10g, je développe actuellement des écrans où je fais des calculs en temps réel.
Pour être en temps réel, j'invoque systématiquement la built-in POST dans le trigger niveau bloc WNRI.

Une (pernicieuse) conséquence est qu'après un appel à POST, je ne suis plus capable d'identifier les records qui ont été modifiés par l'utilisateur.
En effet, les variables systèmes telles que :SYSTEM.RECORD_STATUS sont passés de INSERT ou CHANGED à QUERY.

Existe-t-il une alternative ou un moyen permettant de connaître les records modifiés mais non validés par COMMIT ?

[salim11]

Salut,

Je propose de créer dans ton block une case à cocher,
et avant ton post tu créer un timer , et dans le when-timer-expired
tu coches les enregistremets qui ont le statut <>'QUERY'.

[Magnus]

Bonjour salim11 et merci de votre réponse.

Votre solution me plaît bien mais ce bloc est associé à une table et dans mes écrans, j'ai des traitements complexes qui requierent des appels à CLEAR_FORM.
L'invocation de cette dernière m'oblige donc à modifier la structure de ma table pour stocker la valeur de la case à cocher (ce que je préfère éviter) ou alors à utiliser une autre solution.

Voyez-vous un moyen de compléter simplement votre procédé avec ces informations ?
Si vous avez une autre idée, je suis aussi preneur

[plaineR]

Salut Magnus,

Pourquoi as-tu besoin de savoir quels sont les enregistrements modifiés ?

Je ne pense pas qu'il y ait de mécanique native dans forms pour mémoriser quels sont les enregistrements modifiés.

Une autre solution est de stocker par exemple dans une table temporaire les enregistrements modifiés/insérés lors de chaque post (en stockant clé primaire/unique).
=> lorsque tu committeras ils seront automatiquement effacés de ta table temporaire.

[salim11]

Bonjour

L'invocation de cette dernière m'oblige donc à modifier la structure de ma
table pour stocker la valeur de la case à cocher (ce que je préfère éviter) ou
alors à utiliser une autre solution.

j'ai oublié de te dire que la case à est non basé
donc dons le when-trigger_expired

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
begin 
go_block('****');
first_record ;
loop 
exit when :system.last_record='TRUE';
IF :SYSTEM.RECORD_STATUS<>'QUERY'
Cocher la case à cocher ;
end ;
end loop;
end ;

[Magnus]

Bien sûr, je l'avais compris comme cela que la case à cocher devait correspondre à un item non basé.
Le problème ne se pose pas lors du when-timer-expired mais bien lorsque je fais appel à CLEAR_FORM ou à CLEAR_BLOCK.
Ah mais que je suis bête, après ces 2 instructions, quel que soit le record, la case doit être décochée jusqu'à ce que l'utilisateur effectue au moins une modification et que le timer se déclenche à nouveau.

Hum... je vais approfondir ma réflexion parce qu'effectivement ces 2 built-in ne génèrent aucun souci.

Je vous tiens au courant.
Merci

[plaineR]

La solution de salim me paraît pour le moins bien compliquée... et un peu une usine à gaz :
- quand tu vas posté, tes enregistrements vont passé au statut query
=> tu as beau créé un timer à ce moment là, il ne seront jamais marqués comme modifiés, puisqu'ils auront le statut query
- par ailleurs l'utilisation des timers est déconseillé en mode web.

Il vaut mieux que tu flagues une variable (non basée et appartenant à ton bloc mis à jour) dans les triggers pre-update et pre-insert.

Il y a néanmoins quelque chose que je ne comprends pas : quand l'utilisateur fais un clear_block et ne souhaite pas enregistrer ces modifications, les enregistrements que tu as posté ne sont pas rollbackés. Comment gères-tu cela ?

[salim11]

Salut ,

Juste une petite remarque
je déclenche mon timer avant de faire le post les record gardent leurs status

Code :

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

1
2
3
 
declencher le timer ;
post

[plaineR]

Salut ,

Juste une petite remarque
je déclenche mon timer avant de faire le post les record gardent leurs status

Code :

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

1
2
3
 
declencher le timer ;
post

Non pas forcément, parce qu' à mon avis le post commence avant que le timer n'est flaggué tous les enregistrements. En plus les triggers pre-update et pre-insert sont là pour cela, alors autant les utiliser

[salim11]

Salut ,

c'est vrai un timer est déconsillé à l'utiliser souvent mais dans des cas ou on a pas d'ici en l'utlise
exemple
dans le when-validate-record j'ai pas le droit d'utliser le go_item mais si j'utilise un timer dans son when-timer_experired je peux mettre le go_item

Je vois bien qu'avec le timer pose des problèmes , en utilisant ta solution ca evite tout ca

Code :

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

1
2
3
create tomporary table 
la remplir par les trigger pre-update et pre-insert

[Magnus]

Hello tous les 2,

- par ailleurs l'utilisation des timers est déconseillé en mode web

Ah bon et pourtant ce n'est pas le 1er écran où j'utilise des timers. Le seul inconvénient que j'ai rencontré jusqu'à maintenant est que selon les configurations, le paramètre de durée du timer peut varier.

[/quote]quand l'utilisateur fais un clear_block et ne souhaite pas enregistrer ces modifications, les enregistrements que tu as posté ne sont pas rollbackés. Comment gères-tu cela ?[/QUOTE]
plaineR, sauf erreur de ma part, CLEAR_BLOCK comme CLEAR_FORM annule l'invocation de POST.
En tout cas, je n'ai pas de message de conflit, ni de sauvegarde de modifications que j'aurais souhaité annulé.

[Magnus]

...le post commence avant que le timer n'est flaggué tous les enregistrements

A mon sens, on ne peut pas prédire si le timer va être déclenché avant ou après le POST.
D'ailleurs, d'une exécution à l'autre, il se peut qu'il soit déclenché une fois avant et une fois après, comme 2 fois avant ou 2 fois après.
Rien n'est garanti et c'est justement l'inconvénient des timers.
Me trompe-je ?

[plaineR]

Ah bon et pourtant ce n'est pas le 1er écran où j'utilise des timers.

J'ai dit déconseillée, pas proscrite.

plaineR, sauf erreur de ma part, CLEAR_BLOCK comme CLEAR_FORM annule l'invocation de POST.

Ah non, c'est justement là le problème. Si dans la même session oracle, tu vas dans un autre fmx et que tu commites, les modifications faites dans le fmx où tu as posté seront également commitées. Seul le clear_form (full_rollback) annule toutes les modifications.

A mon sens, on ne peut pas prédire si le timer va être déclenché avant ou après le POST.
D'ailleurs, d'une exécution à l'autre, il se peut qu'il soit déclenché une fois avant et une fois après, comme 2 fois avant ou 2 fois après.
Rien n'est garanti et c'est justement l'inconvénient des timers.
Me trompe-je ?

Pour moi (je ne suis pas un spécialiste des times, je les utilise rarement car cela provoque souvent des usines à gaz...), le timer s'exécute en même temps (ou après suivant le temps défini) que la suite du code. Dans ton cas parcourir tous les enregistrements pour cocher ceux dont le statut est différent de query est une action longu, donc c'est pour cela que je disais que le post aura commencé (et sans doute fini) avant que le timer n'ait parcouru toutes les lignes.

Encore une fois dans ton cas tu as vraiment intérêt à utiliser les triggers PRE-UPDATE et PRE-INSERT. C'est tellement plus simple, je ne comprend même pas que tu veuilles utiliser un timer

[Magnus]

J'ai dit déconseillée, pas proscrite.

Oui mais justement ni dans la doc, ni sur ce forum, je n'avais rencontré de contre-indication des timers. Saurais-tu pourquoi ils sont déconseillés ?

Ah non, c'est justement là le problème. Si dans la même session oracle, tu vas dans un autre fmx et que tu commites, les modifications faites dans le fmx où tu as posté seront également commitées. Seul le clear_form (full_rollback) annule toutes les modifications.

avant d'invoquer un quelconque écran, j'appelle CLEAR_FORM(NO_VALIDATE) par sécurité donc, sans le savoir, j'ai agit comme il le fallait, non ?

Encore une fois dans ton cas tu as vraiment intérêt à utiliser les triggers PRE-UPDATE et PRE-INSERT. C'est tellement plus simple, je ne comprend même pas que tu veuilles utiliser un timer

En fait, je ne veux pas utiliser les timers suite à ta démonstration donc je vais étudier la faisabilité avec les triggers PRE-UPDATE et PRE-INSERT.

Merci à tous les 2 de votre intense participation.

[plaineR]

Oui mais justement ni dans la doc, ni sur ce forum, je n'avais rencontré de contre-indication des timers. Saurais-tu pourquoi ils sont déconseillés ?

1. Parce que cela crée une charge réseau : c'est le poste client qui envoie une demande au serveur forms et celui-ci répond au poste client
2. Parce que tu sollicites le serveur web, il vaut mieux créer un javabean timer qui sera exécuté sur le poste client.
3. Parce que souvent leur utilisation peut-être contournée (avis personnel )

Si la fréquence d'exécution du timer n'est pas importante, c'est vrai que ce n'est pas trop pénalisant.

avant d'invoquer un quelconque écran, j'appelle CLEAR_FORM(NO_VALIDATE) par sécurité donc, sans le savoir, j'ai agit comme il le fallait, non ?

Je ne suis pas sûr que cela soit suffisant, puisque tu ne fais pas de rollback. Il faudrait tester.

[Magnus]

Je ne suis pas sûr que cela soit suffisant, puisque tu ne fais pas de rollback. Il faudrait tester.

Si nous ne somme pas sûrs la doc sur la built-in POST est catégorique :

Any data that you post to the database is committed to the database by the next COMMIT_FORM that executes during the current Runform session. Alternatively, this data can be rolled back by the next CLEAR_FORM

[plaineR]

Si nous ne somme pas sûrs la doc sur la built-in POST est catégorique

Exact

[salim11]

Salut,

Dans notre cas c'est vrai la solution de plaineR est la meilleure, mais dans des cas j'utilise un timer pour trouver une issue à mon problème.

par exemple : je suis dans un trigger et je veux mettre une instruction qui est interdite dans ce trigger, alors dans ce cas j'utilise le timer et dans le
when-timer-experied je mets mon instruction

est ce que vous avez d'autres idées ?

[Magnus]

Comme toi, j'ai souvent besoin d'utiliser des procédures restreintes dans des triggers pour lesquels c'est interdit.
Cependant, j'évite d'utiliser le trigger WTI comme un "fourre-tout" :
- car ce procédé serait antinomique par rapport à une programmation objet
- l'exécution de ce déclencheur est plutôt imprévisible dans la mesure où il s'exécute en parallèle du reste du code.

La plupart du temps, j'estime qu'on dispose d'assez de triggers pour ne pas utiliser WTI.
En effet, j'ai souvent recours à ceux-ci :
- when-validate-record, when-validate-item
- when-button-pressed
- when-new-record-instance, when-new-item-instance
- when-list-changed
- ...

Enfin, par expérience : j'ai installé un écran en production qui effectuait un traitement long et complexe dans un timer (je n'avais pas d'autre choix) sur un site en production dont le serveur est une configuration matérielle très proche de l'une des notres.
Seul souci, j'ai été obligé de mettre le délai du timer paramétrable car pour avoir le bon comportement à l'exécution, le client ne dispose pas du tout de la même valeur que nous sur notre serveur.
Je n'ai pas croisé plus loin mais j'en ai conclu que cette "surprise" était à imputer au WTI

[salim11]

Salut,

Merci Magnus