Discussion :

[SuperDidou]

Bonjour,
je voudrais poser le cas suivant:

J'ai un certain nombre de forms sous 6i qui tournent avec une base 10g. Je dois gérer l'accès aux forms à travers des database triggers AFTER LOGON et BEFORE LOGOUT. Mes forms renseignent le champ CLIENT_INFO (la vue v$session) au moment du PRE-FORM trigger. Mais lorsque je consulte ma table de log (une table custom et non une créé par Oracle), je m'apercois que systématiquement le champ CLIENT_INFO semble ne pas avoir été encore renseigné c.a.d qu'au moment ou le after logon trigger est executé la Forms n'a pas encore écrit de données alors que pour le BEFORE LOGOUT tout est nikel... est-ce un problème de timing entre ces différents évènements (ce que je soupconne d'ailleurs) et si oui, comment contourner ce problème? A noter que j'utilise le package dbms_application_info pour initialiser mon CLIENT_INFO . J'ai bien essayé d'utiliser au niveau Forms d'autres triggers comme ON-LOGON ou POST-LOGON mais rien n'y fait (ou j'ai uen erreur parce que la connexion n'est pas encore faite, ou alors je me retrouve au scénario décrit ci-dessus).

Merci.
Didier

[Garuda]

Mes forms renseignent le champ CLIENT_INFO (la vue v$session) au moment du PRE-FORM trigger. Mais lorsque je consulte ma table de log (une table custom et non une créé par Oracle), je m'apercois que systématiquement le champ CLIENT_INFO semble ne pas avoir été encore renseigné c.a.d qu'au moment ou le after logon trigger est executé la Forms n'a pas encore écrit de données alors que pour le BEFORE LOGOUT tout est nikel

Un question : fais- tu un COMMIT apres avoir écrit danst ta table custom ?

[SuperDidou]

Oui je fais bien un commit. Ce qui me mets la puce a l'oreille c'est que justement lorsque CLIENT_INFO est nul, je mets des logs par défaut donc juste après avoir lancé ma forms test, je fais un select * dans ma table log, et je trouve bien une ligne supplémentaire mais ses valeurs sont celles 'par défaut'. Tu verra dans la capture d'écran, tous les tuples avec le program_name = 'N/A' sont mes tentatives de logon depuis la Forms test et bizarrement pour chaqu'une, tu as une entrée correspondante avec les bonne valeurs qui représente chaque log-out qui s'en est suivi. Pou les log-ins 'par défaut', j'ai eu l'astuce de mettre le session id dans le champ username e.g 28610,28609 etc ..et crois moi si tu veux mais lorsque je fais un select * from v$session where ausid= 28610 , le champ CLIENT_INFO est bien renseigné (en fait je n'y mets que le nom de la forms et son numero de version). Je m'arrache les cheveux avec depuis ce matin et je suis persuadé que c'est la un problème de synchro entre ma forms et ma base... probable je j'utilise les mauvais triggers.

[SuperDidou]

Voici le code que j'utilise por récupérer ces info depuis la vue v$session et je t'assure que c'est exactement le même que j'utilise pour gérer mon logout...
En fait ce code casse client_into en 2 et renseigne les valeurs program_name et version dans 2 champs (e.g SuperDidi/1.5 )

cursor c_prgm_info is
select substr(client_info,0,(instr(client_info,'/')-1)), substr(client_info,(instr(client_info,'/')+1),length(client_info)), sid, serial#,username
from v$session
where audsid = userenv('sessionid');

[mnitu]

Et Didou réfléchi un peu :
Pour appeler dbms_application.set_client_info il faut être connecté, n’est pas vrai ? Mais quand tu te connecté le trigger AFTER_LOGON se déclanche. Faut-il s’étonner que la zone client_info n’est pas renseigné ?

[SuperDidou]

D'accord, mais quel mécanisme proposerais-tu dans ce cas pour mettre en oeuvre la fonctionnalité décrite?

merci
Didier