v$datafile doit être declaré

Bonjour.
J'utilise Oracle 9i.
J'ai un petit probème avec une procédure stockée PL/SQL. Dans la partie déclaration j'écris :

Code:

---

1 2	TYPE TabData IS TABLE OF V$DATAFILE.NAME;

---

Et cela me renvoie l'erreur :

Code:

---

1 2	PLS-00201 : l'identificateur V$DATAFILE doit être declaré

---

J'essaie de faire

Code:

---

1 2	SELECT * FROM V$DATAFILE;

---

sous SQLPLUS et cela ne retourne pas d'erreur, j'obtiens des résultats.
J'ai aussi essaié de re créer le synonyme publique V$DATAFILE mais cela n'a pas résolu mon problème.
Alors que si j'execute la même procédure sous Oracle 8 ça marche, il n'y a aucune erreur.
Est-ce que quelqu'un pourrait m'expliquer? Je suis pas expert en PL/SQL.
Merci.

Il manque le %type:

Code:

---

1 2	TYPE TabData IS TABLE OF V$DATAFILE.NAME%TYPE;

---

Pour mémoire, on met %TYPE pour préciser que le type est le même que la colonne prise en référence,et %ROWTYPE pour préciser que la structure est la même que la table ou la vue prise en référence

Désolé, c'est moi qui ai oublié de mettre %type dans mon message, mais dans la procédure j'ai bien mis %type. Je ne sais pas pourquoi cela ne marche pas.

Tu l'as peut être déjà fait, mais bon, as-tu regardé que le schéma qui contient ta procédure stockée a bien accès à la vue en question ?
Ainsi que le user qui compile la procédure

note que la vue ne s'appelle pas V$DATAFILE mais "SYS"."V_$DATAFILE" !

Il faut donc avoir un grant sur la vue et non sur le synonyme.

Code:

---

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

SQL> grant create session, create procedure to u identified by u;   Grant succeeded. SQL> grant select on sys.v_$datafile to u;   Grant succeeded. SQL> connect u/u Connected. SQL> create or replace procedure p is 2 type tabdata is table of v$datafile.name%type; 3 begin null; end; 4 /   Procedure created.

---

Bonjour.
Merci pour vos réponses. Pour l'instant j'ai un petit problème avec mon ordi, mais dès que ce sera reglé je vais essayer les solutions que vous aviez proposées, et je vous communiquerai la suite.
Merci.

Bonjour à tous.
Désolé d'avoir mis tout ce temps pour répondre.

Citation:

---

Il faut donc avoir un grant sur la vue et non sur le synonyme.

---

Citation:

---

Tu l'as peut être déjà fait, mais bon, as-tu regardé que le schéma qui contient ta procédure stockée a bien accès à la vue en question ?
Ainsi que le user qui compile la procédure

---

Effectivement c'est vrai : des que j'ai attribué le privilège select sur la vue sys.v_$datafile à l'utilisateur propriétaire de la procédure l'erreur n'est plus apparue.
Mais ce que je ne comprends pas, c'est que cet utilisateur possèdait déjà le rôle DBA. Un utilisateur à qui on a attribué ce rôle n'a-t-il pas le droit de consulter n'importe quel objet de la base?
En tout cas merci beaucoup pour vos réponses.

oui, c'est une question courante, le role DBA (ou tout autre role) ne te permets pas d'accèder en PLSQL à des objets qui ne t'appartiennent pas et sur lesquels tu n'as pas de droit directs. Par contre le privilège système SELECT ANY DICTIONARY te permet d'accéder à toutes les vues systèmes, même en plsql.

Et ce n'est pas un bug, c'est une fonctionnalité :aie:

oui, et ça ne changera jamais pour des questions de sécurité. En effet, un role est dynamique, cela veut dire que l'on peut y enlever ou y ajouter des privilèges qui seront immediatement actifs. Par contre un privilege table ou système n'est actif que lorsque l'utilisateur se reconnecte.

Oui mais j'avoue ne pas bien voir l'intérêt d'un point de vue de la sécurité... on change pas les privilèges d'un role comme ça... c'est bien qu'on veut que ce soit appliqué à tous les grantees d'un rôle.

Merci de tes lumières pour enfin m'expliquer ce qui reste un mystère pour moi :mrgreen:

Citation:

---

Envoyé par orafrance

Oui mais j'avoue ne pas bien voir l'intérêt d'un point de vue de la sécurité... on change pas les privilèges d'un role comme ça... c'est bien qu'on veut que ce soit appliqué à tous les grantees d'un rôle.

Merci de tes lumières pour enfin m'expliquer ce qui reste un mystère pour moi :mrgreen:

---

AMHA, Ce que je vois comme intérêt c'est que la vérification se fait au moment de la compilation du fait (puisqu'il faut être connecté pour que les droits sont pris en compte)
De fait, un package compilé fonctionnera.

Si ce n'étaita pas le cas, lors de modification d' un rôle, par effet cascade, le package compilé ne fonctionnerait plus ce qui serait infernal à gérer.
Tu touches à un rôle applicatif et tu as toute une partie de l'application qui tombe

là, tu es de fait obligé de dire expréssément que tu touches à tel utilisateur; la portée des modifications est donc bien moindre, le risque de tout planter nettement plus réduit.
Bref, c'est mieux ! :)

mais mon explication n'est peut-être pas la bonne...

à oui, en effet, pour la validation du code c'est plus pratique... m'enfin, si c'est juste une "rustine" technique il n'y avait qu'à pas vérifier les droits lors de la compilation :mrgreen:

ça ne va jamais changer, ça serait un trop gros risque pour la sécurité.

Un exemple pourquoi un rôle dynamique est vital :

Si un utilisateur est connecté et qu'une nouvelle table est créée pour l'application, alors on peut donner un select au role et pas besoin pour l'utilisateur de se reconnecter!

et tu continues à avoir un package compilé non exploitable ! ;)

Citation:

---

Envoyé par orafrance

il n'y avait qu'à pas vérifier les droits lors de la compilation :mrgreen:

---

oui mais si tu as le droit lors de la compilation et non lors de l'exécution, alors il y a un trou dans la sécurité. Il faudrait alors invalider les procédures à chaque changement de rôle.

Leo :arrow: c'est pas faux... mais c'est déjà le cas aujourd'hui. Imagine un user qui crée un package. Le package sera valide si le owner a les droits mais personne ne pourra le lancer si ils n'ont pas eux aussi les priviléges sur les objets. c'est à dire que quand tu crées un user tu es obligé de granter les objets à ce user même s'il a un rôle suffisant, ce qui évidemment est très lourd en terme de maintenance :?

j'espère être clair :oops:

Laurent :arrow: OK, mais la question qui me géne c'est pourquoi les privilèges d'un rôle ne sont pas pris en compte dans le code PL/SQL... je veux dire, en quoi ça apporte de la sécurité en plus du rôle ?

Citation:

---

Envoyé par laurentschneider

oui mais si tu as le droit lors de la compilation et non lors de l'exécution, alors il y a un trou dans la sécurité. Il faudrait alors invalider les procédures à chaque changement de rôle.

---

oui mais après réflexion c'est déjà le cas :koi: Un package peut être valide même si l'utilisateur qui veut l'utiliser n'a pas les droits nécessaires... c'est bien ce qui pose autant de problème aux débutants qui n'arrivent pas à saisir ce souci :?

ouais, bon, c'est vrai que c'est un peu une question de design.

Mais sur le principe, les privileges d'un rôle sont dynamique. Donc si par exemple j'obtenais via un rôle pendant 1 jour le droit SELECT sur EMPLOYEE, je pourrais alors me créer une vue ou une procedure qui resterait valide même lorsque le droit serait ôté du rôle.

Tu vois le genre?

C'est pourquoi que je me dis que ça ne changera pas avant la version Oracle 1.0 :aie: (ou Oracle XP ou Oracle 97.5)

Citation:

---

Envoyé par orafrance

oui mais après réflexion c'est déjà le cas :koi: Un package peut être valide même si l'utilisateur qui veut l'utiliser n'a pas les droits nécessaires... c'est bien ce qui pose autant de problème aux débutants qui n'arrivent pas à saisir ce souci :?

---

Oui, c'est toute la différence entre les privilèges (non-dynamiques) et les rôles (dynamiques)

C'est pourquoi il est plus sage et plus pratique de distribuer les droits SELECT via un rôle.

Bien sûr, c'est très gênant pour celui qui n'est pas au courant ...