Discussion :

[zxr69]

Bonjour,

Je souhaiterais effectuer l'operation suivante : creation d'un user avec des acces en lecture (enfin, a la limite peu importe) sur un schema existant ... en fait mon pb se situe a ce niveau la : depuis SQL je suis oblige d'utiliser la syntaxe suivante 'select * from "nom_schema"."nom_table"', alors que je souhaiterais pouvoir utiliser la syntaxe 'select * from nom_table'

Si quelqu'un a une idée, cela m'aidera grandement !!!

Merci.

[Jaouad]

Bonjour ,

Pour donner la permission de lecture sur une table :

grant read on table to user ;

Pour pouvoir attaquer une table sans mettre le nom du schéma il suffit de créer un synonyme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
SQL> grant select on ps_job to test ;
 
Autorisation de privilèges (GRANT) acceptée.
 
SQL> conn test/test 
Connecté.
SQL> select count (*) from ps_job ;
select count (*) from ps_job
                      *
ERREUR à la ligne 1 :
ORA-00942: Table ou vue inexistante
 
 
SQL> select count (*) from sysadm.ps_job ;
 
  COUNT(*)
----------
       259
 
SQL> create synonym ps_job for sysadm.ps_job ;
 
Synonyme créé.
 
SQL> select count (*) from ps_job ;
 
  COUNT(*)
----------
       259
 
SQL>

[pifor]

Il faut créer un synonyme:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CREATE SYNONYM <synonyme> FOR <schema>.<table>;

ou changer le schéma par défaut avec:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ALTER SESSION SET CURRENT_SCHEMA=<schema>;

[zxr69]

Quelle rapidite .....

Avec mes remerciements ....vraiment

Comment modifier cet "ALTER SESSION" pour l'integrer dans un code VB par exemple, qui comporte plusieurs requetes SQL ?

derniere petite question : apparement, mon client SQL PLUS est "case sensitive" sur les noms des tables par exemple ... comment eviter cet "inconvénient" ?

[Jaouad]

A mon avis il faut éviter le alter session et se servir des synonymes.

Pour éviter le case sensitive, il suffit tout simplement de ne pas créer les tables entre double-quote et de ne pas les appeller avec les double-quote

[pifor]

Comment modifier cet "ALTER SESSION" pour l'integrer dans un code VB par exemple, qui comporte plusieurs requetes SQL ?

C'est n'est qu'une commande SQL qu'on peut mettre en début de connexion à la base de données par exemple si on est sûr de toujours travailler dans le même schéma.

derniere petite question : apparement, mon client SQL PLUS est "case sensitive" sur les noms des tables par exemple ... comment eviter cet "inconvénient"

Bizarre ... peut-être que vos tables ont été créées avec le nom entres " " ?
Le dictionnaire de la base stocke les noms en majuscule mais ne fait pas de différence minuscules/majuscules en SQL sauf si on utilise les " " en créant les objets.

[zxr69]

Merci pour toutes ces reponses ....

J'ai resolu mon pb de " " ....

Est-il possible de preciser une bonne fois pour toute le schema par defaut "associé" a un user ????

[pifor]

Avec Oracle 9 ou 10, cela peut se faire avec un LOGON TRIGGER.

[zxr69]

Tu vas dire que j'abuse si je te demande une petite aide sur le sujet ?

[pifor]

Oui, parce que je n'ai pas utilisé cette fonctionnalité.

Mais il y a un exemple là: http://oracle.developpez.com/faq/?page=3#afterlogon

[zxr69]

Le trigger est bien créé .. mais ne fonctionne pas ..... lorsque je me connecte sous Sql Plus par exemple ..... je suis obligé de me caler sur le bon schema, alors qu'il devrait le faire de suite apres mon logon ....

des idées ?

[orafrance]

et dans glogin.sql, le fichier de paramètre de SQL*Plus ?

[zxr69]

Rien de particulier dans ce fichier ....

Bon je vais faire un petit resumé de mon souci ....

je souhaite pouvoir me connecter a un schema avec un user, depuis SQl plus ou tout autre objet Vb, DAO, ADO, etc ..... sans a chaque fois repréciser que c'est tel schema que je souhaite utiliser ....

[zxr69]

Bon je me suis resolu a créer des synonymes et ca fonctionne parfaitement ....

Merci a tous pour votre aide precieuse ....