Comment faire pour se connecter a la base de Oracle avec Forms
Pour se connecter il faut le nom de la base mais forms repond qu il ne trouve pas l'adresse symbolique de la base quand je lui donne le nom de la base...
 
ca signifie quoi?
qu est ce qu il faut lui donner comme nom pour avoir une connexion a la base?
 
j'ai vu fonctionner forms sous linux avec une connexion a une base correcte (le nom de la base est alors '/')
j'utilise forms sous windows mais il y a surement qqchose a configurer mais j'ignore quoi.
 
merci de votre aide

question annexe : si je dois avoir une contrainte d'association minimum, comment je peux procéder (un exemple crétin : une personne doit emprunter minimum 2 livres, il est impossible de remplir un emprunt unique donc)
pour ca j'utilise un trigger pour empecher un emprunt et je cree une procedure pour creer des paquets d emprunts
mais le probleme c que le trigger est bloquant dans la procedure est qu'il est impossible de desactiver des triggers dans une procedure
y a t il une autre solution ou faut il laisser les utilisateurs pouvoir ajouter des emprunts uniques (pour rester dans l'exemple) ou alors il faut jouer avec les droits d utilisateurs en interdisant toutes operations sur les emprunts sauf par la procedure (mais cette solution me parait un peu bizzare...)
 
encore merci d avance

un ptit UP

Dans le client Oracle pour windows, tu configure les connexions en donnant un nom symbolique à une base.
J'ai pas çà sous la main içi chez moi pour répondre plus précisément.

g reussi a le configurer. Merci
qqun peut il m'aider pour la question annexe?

Fauyt utiliser SRW.DO_SQL pour désactiver ton trigger dans ta procédure.

ok merci je vais essayer ca.

J'ai essaye d'utiliser Srw mais ca ne fonctionne pas.
D apres ce que j'ai trouve c un package mais comment l'utiliser?
Il faut importer quelquechose?
 
Le message d'erreur est que srw n'est pas un objet.
voila tout ce que j'ai trouve d'interessant sur ce package et ca n explique pas comment s'en servir (juste des infos et des appels de procedure du package)
http://otn.oracle.co.kr/docs/oracl [...] b/ch32.htm
 
Merci d'avance

ben jai toujours pas trouvé...
qqun peut il m aider?
 
on ma dit qu il etait possible d'utiliser 'Execute(requete SQL)' pour faire une requete SQL dans une proédure aussi
 
alors je vais aller essayer ca pour voir si ca marche...
sinon toute aide est la bienvenue.
merci

Désactiver un trigger dans une PROC !
Même si c'était possible, c'est super dangereux. Si la proc plante, ton trigger reste désactivé.
A mon avis t'a intéres à changer de stratégie.
 
Exemple de piste :
Ajoute un champs "statut" dans ta table d'emprunt.
statut = 0 -> En saisie
status = 1 -> Validé
 
Dans ta proc, tu crées tes emprunts en statut 0, et ensuite, tu les passe en 1.
 
Dans le trigger (qui interdit les emprunts uniques) tu bloque seulement si il y a un seul emprunt avec un statut à 1. Tous les autres cas passent.
 
Autre piste :
Dans ta proc
old_env := userenv('CLIENT_INFO');
DBMS_APPLICATION_INFO.SET_CLIENT_INFO( 'PROC_EMPRUNT' );
...
-- création des emprunts
...
DBMS_APPLICATION_INFO.SET_CLIENT_INFO( old_env );
 
Dans ton trigger, tu ne fait pas de vérif si
userenv('CLIENT_INFO') = 'PROC_EMPRUNT'
 
Mais çà revient à désactiver le trigger, donc si ta proc plante, il faut un truc pour changer la valeur de 'CLIENT_INFO'
 
Finalement :
Si toutes les créations d'emprunts passent par ta proc, ben ton trigger ne sert pas à grand chose !

Pour exécuter une requête SQL construite à la main (dans un varchar2) depuis une form, tu peux utiliser :
forms_ddl('requête');
Avec un éventuel commit...

la premiere piste me parait repousser le probleme...
d accord on pourra alors gérer les emprunts correctement mais je pars du principe que l'utilisateur est un débile profond qui peut changer tous les attributs...
donc si il peut changer la valeur de cet attribut, c cuit.
et si je l en empeche cela revient juste a empecher la creation d'emprunt directement et a forcer a utiliser la procedure de creation.
donc ca revient a peu pres au meme
 
j avais bien pensé a cette solution (bloquer les creations directement) mais je voulais pouvoir laisser tous les droits a l'utilisateur (et je ne savais pas trop si changer les droits de la base etait tres correct)
 
en fait oui je voudrais que tous les emprunts passent par la procedure mais je ne savais pas comment bloquer les insertions correctement.
 
en revanche c vrai que je n avais pas pensé au plantage de la procédure qui ferait que le trigger reste désactivé.
 
en ce qui concerne la deuxieme piste je dois dire que je n y comprend rien...
a creuser plus tard mais je pense que je vais me contenter de bloquer les acces directs et de forcer a utiliser la procedure.
 
merci
 
Vinx:c t pas trop ma question mais ca pourra peut etre me servir
merci

'CLIENT_INFO' est une variable du contexte d'execution.
 
En fait il vaut mieux créer un contexte spécial pour ce que tu veut faire.
 
Le principe :
 
1- Créer un contexte et lui associer un package.
 
2- Créer le package qui va contenir des fonctions pour écrire dans le contexte. Seul les fonctions de ce package pouront le faire
 
3- Utiliser le contexte.
 
Donc je reprend :
1- Créer un contexte et lui associer un package.

 
2- Créer le package :

 
 
3- Utiliser le contexte.
 
Donc, dans le trigger tu fait :
 

 
Dans ta procédure, tu fait :  

 
Ce qu'il faut bien conprendre, c'est que le contexte est propre à la session de l'utilisateur. Quand il fait une mise à jour dans une table et qu'un trigger se déclanche, son code s'execute dans la même session, et donc il partage les même infos de contexte.
Si la procédure se plante, il se peux que le trigger ne soit plus 'locked'. Mais ce n'est vallable que pour cette session de l'utilisateur. S'il ferme l'appli et l'ouvre de nouveau, le contexte est reinitialisé.
 
Je te remercie de ta question.
Je ne connaissais pas les contextes avant. J'en avait vaguement entendu parler, mais s'était très nébuleux pour moi. Maintenant les nuages commencent à s'écarter, et je vois la lumière

Pour s'assurer que l'utilisateur de fasse pas appel à "emprunt.lock()", en fait il vaut mieux que TA procédure soit dans le package Associé au contexte
A ce moment là, plus de "emprunt.lock()", tu fait dirrectement appel à "DBMS_SESSION.SET_CONTEXT(...)" dans TA procédure.
 
Bien sûr, il faut aussi des triggers en DELETE et UPDATE

Je voudrai à partir d'un champs texte dans un canevas ou une adresse e-mail est rensignée, ouvrir outlook express et me placer directement sur nouveau message avec l'adresse qui se trouve dans mon champs comme étant le destinataire