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é