AFTER LOGON et init des variables de session [Résolu]

[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

[SuperDidou]

...oui, proposer une solution en tenant compte qu'il soit impératif de garder l'option AFTER LOGON trigger pour gérer les droits d'accès.

merci

[mnitu]

Commençons par mettre les boeuf avant la charrue : décrit ton besoin. Apres on pourrait examiner les solutions.

[SuperDidou]

D'accord! (ouf enfin une réponse )

Bon. J'ai des forms oracle. Pour chacune d'entre elle, je veux venir renseigner le nom du module (de la forms et sa version). Pour l'instant, j'utilise le set_client_info du package dbms_application_info dans les triggers PRE-FORM de mes forms pour renseigner ce champ.
Coté SGBD, j'utilise le trigger AFTER LOGON pour gérer les tentatives de connexion. C'est dans le trigger after logon que je viens récupérer le client_info pour déterminer qui essaie de se connecter a la base et à travers quel Forms. L'utilité de ce mecanisme est de me permettre de savoir le username et le nom de Forms qui a déclenché le logon; ceci pour ensuite aller chercher dans une table custom si ce user a la permission d'utiliser ladite form. Je tiens aussi des logs de qui a essayé de faire quoi mais la encore ce sont des traces bêtes et méchantes.
Voila

[mnitu]

Envoyé par SuperDidou

...C'est dans le trigger after logon que je viens récupérer le client_info pour déterminer qui essaie de se connecter a la base et à travers quel Forms. L'utilité de ce mecanisme est de me permettre de savoir le username et le nom de Forms qui a déclenché le logon; ceci pour ensuite aller chercher dans une table custom si ce user a la permission d'utiliser ladite form. ...

Désolé mais ce mécanisme ne peut pas fonctionner :
L’application forms se connecte à la base
Le trigger after logon se déclanche à ce moment client_info est nulle
Le trigger fini son exécution
Maintenant l’application forms appelle dbms_application.set_client_info
Je pense que les seules informations disponibles pendant l’exécution du trigger sont

ora_sysevent
ora_login_user
ora_instance_num
ora_database_name
ora_client_ip_address

Pour l’instant la seule solution conceptuelle qui n’est pas farfelue est de tester la permission d’accès dans la couche applicative et non pas dans le trigger After Logon. Cela ne vous convient pas ?

[SuperDidou]

Merci,
Sa reste en effet une option pour moi et je pense que finalement je vais me rabattre la-dessus ne serait-ce que pour gérer la partie log-in.
Merci beaucoup
Didier