[Forms 9i] qui déclenche un FORM_FAILURE suite à EXECUTE_QUERY ?

Bonjour,

Sous forms 9i, j'ai un scénario que je ne peux expliquer.
Dans un trigger KEY-NXTBLK, j'ai le code suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

...   GO_BLOCK('MS');   CLEAR_BLOCK (NO_VALIDATE); if form_failure then msg_box('1 - form_failure'); end if;   EXECUTE_QUERY(ALL_RECORDS,FOR_UPDATE);   if form_failure then msg_box('2 - form_failure'); end if;   ...

---

A l'exécution, j'ai le message suivant qui s'affiche : "2 - form_failure".
J'ai vérifié en débug : FORM_FAILURE qui est à FALSE avant l'appel à EXECUTE_QUERY est à TRUE juste après.

Comment localiser l'intruction qui déclenche ce changement de FORM_FAILURE ?

Merci d'avance.

si execute_query générer une erreur tu passes en failure non ?

Citation:

---

Envoyé par Fred_D

si execute_query générer une erreur tu passes en failure non ?

---

Je suis tout-à-fait d'accord Fred mais je ne sais pas comment procéder pour connaître le trigger, la procédure interne, etc. invoqué par EXECUTE_QUERY et qui provoquerait cette failure.

J'ai essayé en débug de positionner un point d'arrêt sur EXECUTE_QUERY et de faire un 'step into (F7)', mais je suis resté dans mon trigger KEY-NXTBLOK.

Comment puis-je faire pour savoir si cette failure est généré par EXECUTE_QUERY dans ce traitement interne ou par un bout de mon écran ?

J'apporte des infos supplémentaires des fois qu'une personne ait une idée (géniale) :
- j'ai vérifié que chaque item base table du bloc MS ait le même type de données et la même précision qu'en base : OK
- j'ai créé un trigger dans ce bloc (MS) PRE-QUERY qui est bien invoqué après l'appel à EXECUTE_QUERY. Dans ce trigger form_failure vaut encore FALSE.

Remarques :
- juste après l'appel à EXECUTE_QUERY, la variable système :SYSTEM.LAST_QUERY vaut :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

SELECT ROWID,T84_LIEUMS,T85_AIREMS,ES_NUM,ES_NIV,OF2_CUMPREL, OF2_QTPREL,OF2_PAMP,OF2_ACTI,OF_NUM,OF_COMP,T81_FAM,MS_CODE, T62_ECART FROM B4102 WHERE b4102.of_num = 'F1600316' and b4102.of2_acti = '0' and nvl(b4102.of_comp,0) in (-1,0) and nvl(b4102.of2_qtprel,0) <> 0 and nvl(b4102.of2_qtprel,0) > nvl(b4102.of2_cumprel,0) FOR UPDATE OF T84_LIEUMS

---

Exécutée sous SQLPlus, cette requête ne ramène aucune données (c'est le comportement attendu) et ce qui justifie que je ne passe dans le trigger de ce bloc POST-QUERY.

Cela vous donne-t'il des idées parce que je fouille sur Metalink mais je suis VRAIMENT à court d'explications plosibles ?

et si t'affiche la dernière erreur Oracle dans l'écran ?

Salut Fred et merci de t'intéresser à mon problème

Citation:

---

Envoyé par Fred_D

et si t'affiche la dernière erreur Oracle dans l'écran ?

---

Habituellement, quand j'appuie sur la touche F6 et qu'une fenêtre s'ouvre cela signifie qu'une requête de sélection, d'insertion ou de mise à jour sur un bloc a échoué.
Là en l'occurence quand j'appuie sur F6, aucune fenêtre ne s'affiche.
J'en déduis que l'origine du form_failure est du à du code utilisateur proprement dit.

N'est-ce pas simplement la clause FOR_UPDATE qui échoue car tous les enregistrements ne peuvent être verrouillés ?
et si vous retirez cette clause ?

Extrait de la doc:

Citation:

---

EXECUTE_QUERY Restrictions Oracle Corporation recommends that you use the ALL_RECORDS and FOR_UPDATE parameters with caution. Fetching a large number of rows could cause a long delay. Locking a large number of rows at once requires many resources.

---

sans doute aucun lien direct, mais toujours bon à savoir.

Salut et merci de ta réponse SheikYerbouti

Citation:

---

Envoyé par SheikYerbouti

N'est-ce pas simplement la clause FOR_UPDATE qui échoue car tous les enregistrements ne peuvent être verrouillés ?
et si vous retirez cette clause ?

---

J'ai déjà effectué ce test de 2 manières :
- en supprimant ALL_RECORDS : idem
- en supprimant FOR_UPDATE : idem
- en supprimant les 2 : idem

Citation:

---

Envoyé par SheikYerbouti

...tous les enregistrements ne peuvent être verrouillés

---

Pour information, ce bloc ne doit récupérer aucun enregistrement ; d'ailleurs la requête que j'ai affichée en témoigne sous SQLPlus.

PS : actuellement, je suis en train de positionner des points d'arrêt partout dans les triggers niveau bloc et niveau item en m'appuyant sur le schéma des appels suivant : http://sheikyerbouti.developpez.com/...g/?page=Chap53
Conclusion : une fois EXECUTE_QUERY invoqué, on passe uniquement dans le trigger PRE-QUERY. POST-QUERY n'est pas invoqué car aucune donnée n'est récupérée et enfin, les triggers niveau item de ce bloc WNII ne sont appelés qu'après le retour à la procédure appelante (celle qui invoque EXECUTE_QUERY).

Très sincèrement, j'en perds mon latin et je ne vois plus quel mot clé entrer sous Metalink :roll:

Citation:

---

Pour information, ce bloc ne doit récupérer aucun enregistrement

---

N'est-ce pas justement la raison du FORM_FAILLURE. Si vous ne ramenez aucun enregistrement, vous déclenchez le message : le query ne ramène aucune ligne... qui positionne alors la variable système.

Citation:

---

Envoyé par SheikYerbouti

N'est-ce pas justement la raison du FORM_FAILLURE. Si vous ne ramenez aucun enregistrement, vous déclenchez le message : le query ne ramène aucune ligne... qui positionne alors la variable système.

---

Heu... j'aime beaucoup votre raisonnement d'autant que, dès qu'il existe des données alors form_failure vaut FALSE.
Cependant, d'après la doc, form_failure représente l'état de la dernière instruction exécutée ; en l'occurence EXECUTE_QUERY.
Par conséquent, je ne sais pas trop quoi penser de la notion de failure vis-à-vis du fait que la requête n'a récupéré aucune donnée...

En cas de doute, je considère que l'explication vient de là.

Merci beaucoup.

EXECUTE_QUERY, c'est comme COMMIT, cela engage en fait toute une suite d'autres actions (comme ON-SELECT, ON-FETCH, WHEN-NEW-ITEM-INSTANCE, POST-QUERY, etc...)
donc le statut FORM_FAILURE est effectivement difficile à cibler !

Oui je suis d'accord et ils pourraient le mentionner dans la doc.

Que ce soit pour form_success ou form_failure je trouve que les notions de "succès" et d'"échec" sont floues lorsque la récupération de données s'est déroulée correctement (i.e. pas d'anomalie, exception ou autre) mais qu'il n'existe aucune ligne associée dans la table visée.

Dans tous les cas, j'utiliserai maintenant cette routine avec modération.