Discussion :

[Magnus]

Bonjour,

Je développe des écrans sous forms 10g pour lesquels je souhaite faire des contrôles en TEMPS REEL ; par exemple, faire des contrôles de dispo, etc.
Malheureusement, à l'exécution, j'obtiens souvent ce message d'erreur :

frm-40654 Record has been updated by another user. Re-query to see change.

A priori, ce message est généré lorsqu'un enregistrement a été posté, modifié et que l'on tente à nouveau de le poster.
Cependant, même en utilisant le déboggueur, je n'arrive pas à déterminer précisément l'origine de ce message d'erreur.

Ce message d'erreur n'est plus généré si je supprime toutes les invocations de la méthode POST.
L'ennui est que sans appel à POST, comment valider temporairement les changements apportés par l'utilisateur : ajout, modification ou suppression d'enregistrements ?
Par conséquent, sans cette méthode, mon contrôle de dispo ne tient pas compte des modifications apportées depuis la dernière validation en base par COMMIT.

J'aimerais donc que l'on m'explique :
- ce qui génère ce message d'erreur
- comment travailler en temps réel avec ou sans la méthode POST mais sans ce message d'erreur intempestif.

Merci d'avance aux âmes charitables (et un minimum expérimentées).

[plaineR]

Hello Magnus,

As-tu un trigger sur la table que tu fais un post ?

[Magnus]

Tu peux savoir ce que je suis content de te voir plaineR

As-tu un trigger sur la table que tu fais un post ?

La table en question a les triggers :
- KEY-DELREC
- KEY-DOWN
- KEY-MENU
- KEY-NXTBLK
- KEY-PRVBLK
- KEY-UP
- POST-QUERY
- WHEN-MOUSE-CLICK
- WHEN-NEW-RECORD-INSTANCE -- invocation de POST
- WHEN-VALIDATE-RECORD -- contrôle du dispo par exemple

Des fois que ça serve, voici le code WHEN-NEW-RECORD-INSTANCE :

Code :

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

1
2
3
4
5
6
 
-- ATTENTION : pour pouvoir effectuer des calculs en temps réel, on post toutes les modifications
-- SAUF quand l'enregistrement est en cours de création !!!!
IF :SYSTEM.RECORD_STATUS NOT IN ('NEW') THEN
	POST;
END IF;

[taska]

as tu regardé du côte de ceci:
Select for Update

...
http://www.techonthenet.com/oracle/c...for_update.php

CDLT.

[Magnus]

Salut taska et merci de t'intéresser à cette discussion,

Je connais SELECT FOR UPDATE et WHERE CURRENT OF mais ils ne peuvent pas être appliqués dans ce contexte car les données modifiées sont des items base table.

Ex (simplifié) : supposons la table suivante :

Code :

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

1
2
3
4
5
 
remuneration(
  id_employe number(2),
  salaire       number(12,4)
)

Supposons aussi que j'ai un écran contenant un bloc basé sur cette table et que je fais les manipulations suivantes :
1/ lancement de l'écran
2/ query de tous les records
3/ modification du salaire du record dont id_employe = 12 de 2000 à 3000
4/ déplacement dans un autre record, ce qui implique l'invocation de POST grâce au trigger WHEN-NEW-RECORD-INSTANCE
5/ retour sur le record dont id_employe vaut 12 et modification du salaire de 3000 à 2500
6/ tentative de déplacement sur un autre record, donc invocation du trigger WHEN-NEW-RECORD-INSTANCE donc de POST
FRM-40654

Mon explication : lors de l'invocation du 2ème POST, la valeur de la colonne SALAIRE du record dont id_employe = 12 est :
- en base, 2000
- dans la session, 3000
- à l'écran, 2500
Par conséquent, forms ne peut décider à quelle valeur il doit positionner la colonne de ce record : 3000 ou 2500 ?

[taska]

et passer par un bloc basé sur une procédure stockée ne te donnerais pas plus de flexibilité quand à la partie transactionelle ?

CDLT.

[plaineR]

Je n'ai pas été clair, je parlais de trigger basé

[Magnus]

@plaineR :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
CREATE TRIGGER PR2000_TRIGGER
BEFORE INSERT ON PR2000
FOR EACH ROW
BEGIN
  SELECT PR2000_SEQ.NEXTVAL
  INTO   :NEW.OL_LIGNE
  FROM   DUAL;
END;
/

PS : si j'avais fait un petit effort dans ta direction, j'aurais pu deviner, d'autant plus que je suis tombé sur un document qui en parlait sur Metalink

@taska : ça me paraît bien compliqué pour mettre en place un traitement aussi "banal".
En effet, je voudrais SIMPLEMENT que lorsque l'utilisateur quitte un enregistrement, automatiquement toutes les modifications soient validées en base.
Malheureusement, l'utilisation de POST dans un trigger WVR n'est pas possible et apparemment, modifier un enregistrement qui a été posté soulève une FRM-40654

Je vais vous justifier mon besoin : si j'ouvre une session SQLPlus et que je fais des manipulations DML (INSERT / UPDATE / DELETE) alors tant que je n'ai pas validé mes modifications elles n'ont pas de portée pour les autres sessions, mais durant MA session :
- je ne rencontre pas de message de conflit
- toutes les manipulations tiennent compte des précédentes

La mise en place d'une telle fonctionnalité sous forms est loin d'être aussi évidente.

[plaineR]

OK, as-tu essayé de mettre la propriété de bloc "DML Returning value" à true ?

[Magnus]

C'est une des solutions qu'ils préconisent sur metalink mais je l'avais temporairement écartée car je ne comprends pas cette propriété.
Et effectivement, ça a l'air de marcher

Je vais approfondir mes tests cet après-midi histoire de vérifier que mon besoin est satisfait.
Cependant, je t'avoue que j'ai du mal à comprendre ce que fait cette propriété surtout dans ce contexte (ie j'ai conservé les instructions POST).

Tu peux m'en dire plus ? L'as-tu déjà expérimentée ?

Dans tous les cas, merci plaineR de me dépanner aussi rapidement et efficacement (même pas une ligne de code).

[SheikYerbouti]

DML returning value, permet de relire entièrement le record et de le ré-afficher dans le bloc. Cela permet par exemple de voir certains champs mis à jour ailleurs que depuis Forms (cas d'un champ mis à jour par un trigger basé, par exemple).

[plaineR]

Je l'utilise régulièrement quand j'ai des triggers qui modifient des colonnes d'un bloc que je suis en train de mettre à jour (=> d'où l'erreur "Record has been updated..."). Cette propriété permet de récupérer les valeurs mises à jour par le trigger et évite d'avoir à raffraichir l'affichage.

Ne pensant pas pouvoir être plus précis que SheikYerbouti :

Valeur de retour DML indique si Forms doit utiliser la clause spécifique RETURNING INTO disponible depuis Oracle 9i pour rafraîchir les données du bloc.
Positionner cette propriété à OUI permet de faire l'économie d'un execute_query après la modification des données.

Restrictions:
Une valeur égale à OUI n'est prise en compte que si Forms est connecté à une base 9i ou supérieure.
La clause RETURNING INTO est utilisée pour les insertions et les mises à jour mais pas pour les suppressions.
Cette clause est sans effet lorsque le bloc contient une colonne de type LONG.

[Magnus]

Je n'ai plus ce message d'erreur.
Vous êtes tout simplement magiques !

Ceci dit, j'ai encore 2 questions :
- dans la doc, à propos de cette propriété, il existe cette restriction :

Forms uses the DML Returning clause only with an Oracle8 database server. This property is ignored when using a non-Oracle8 server

Si je la comprends correctement, cette restriction vient en contradiction avec les votres : s'agit-il uniquement de la version 8i ou à partir de la version 9i ?

- ai-je encore besoin de l'instruction POST dans le trigger WNRI (notamment) ?

[plaineR]

Si je la comprends correctement, cette restriction vient en contradiction avec les votres : s'agit-il uniquement de la version 8i ou à partir de la version 9i ?

Je n'ai pas de certitudes pour les bases 8i (peut-être cela fonctionnait-il déjà), mais en 9i et 10g cela fonctionne. Pour le vérifier il suffit que tu affiches la valeur d'un champ modifié par le trigger avant de faire un post ou un commit et de réafficher cette valeur après.

- ai-je encore besoin de l'instruction POST dans le trigger WNRI (notamment) ?

Je ne sais pas à quoi il te sert précisément ici, mais de manière général le post permet d'envoyer à la base de données les informations saisies. Donc si tu le supprimes tu n'envoies plus ces infos à la bdd.

[Magnus]

Ok. Je vais faire quelques tests.
Merci plaineR