ORA-00942 lors de la création d'un trigger

Bonjour à tous,
j'ai une grande interrogation : j'ai le trigger suivant que j'encapsule avec plusieurs autres requêtes SQL pour me faciliter les migrations. (je n'indique que le trigger)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

create or replace TRIGGER MonSchema.TB_REPORT_FAV_TRG BEFORE INSERT ON TB_REPORT_FAV REFERENCING NEW AS NEW OLD AS OLD FOR EACH ROW WHEN ( (NEW.REPORT_FAV_SN IS NULL) OR (NEW.REPORT_FAV_SN =0) ) DECLARE BEGIN SELECT SEQ_TB_REPORT_FAV.NEXTVAL INTO :NEW.REPORT_FAV_SN FROM dual; EXCEPTION WHEN OTHERS THEN RAISE; END TB_REPORT_USER_PARAM_TRG;

---

La table TB_REPORT_FAV n'existe pas, elle se crée correctement mais pas son trigger. Le script de migration échoue avec l'erreur suivante :
ERROR at line 3:
ORA-00942: table or view does not exist

Si je met ON MonSchema.TB_REPORT_FAV je n'ai plus d'erreur mais cela m'ennuie fortement d'associer la table à un schéma dans mon trigger .

J'ai bien vérifié les droits de mon utilisateur et j'ai bien tous les droits ! Alors pourquoi suis je obligé de mentionner mon schéma ?

Version d'Oracle: v11.2.0.1.0
Sous Windows XP 32 bits.

merci à tous !

Si vous ne voulez pas indiquer le schéma il faut que l'utilisateur avec lequel vous vous connectez pointe sur ce schéma.

Mais bon, c'est une bonne pratique de toujours indiquer le schéma des objets, ça lève les ambiguïtés.

Au passage, puisque vous êtes en 11g, vous pouvez écrire :

Code:

---

:NEW.REPORT_FAV_SN := SEQ_TB_REPORT_FAV.NEXTVAL;

---

Il faut créer un synonyme (public ou non) sur la vue.

Merci pour vos réponses :
@Waldar : Si vous ne voulez pas indiquer le schéma il faut que l'utilisateur avec lequel vous vous connectez pointe sur ce schéma.

Comment faire pour que mon utilisateur "pointe" spécifiquement sur le schéma, je lui donne déjà tous les droits sur ce schéma ?

@Garuda : De quelle vue parlez vous ? ma table TB_REPORT_FAV est une vraie table et non une vue.

Enlevez

Code:

---

1 2 3 4 5

... EXCEPTION WHEN OTHERS THEN RAISE;

---

ce code inutile ne sert à rien sinon à cacher le numéro de la ligne où l'erreur se produite.

Citation:

---

Envoyé par Daeron

...mais cela m'ennuie fortement d'associer la table à un schéma dans mon trigger .
...

---

Pourquoi ? Que-est-ce que vous essayez d’accomplir avec ce choix ?

@mnitu : nous avons des scripts pour éviter de nommer les schémas permettant d'avoir des schémas libres. C'est pour cela que l'on souhaitait ne pas nommer les tables dans les triggers.

Qu’est-ce que une « schéma libre » ?

Citation:

---

Envoyé par mnitu

Qu’est-ce que une « schéma libre » ?

---

Un schéma dont le nom n'est pas codé en dur...

En fait, nous laissons libre choix à l'installation de choisir le nom du schéma, c'est très pratique pour la base d'archivage des données, même structure sans les triggers mais schéma différent. On peut l'appeler ainsi comme on veut "toto", "titi", "archive1", "prod" ou comme je l'avais mis "MonSchema". Cela implique donc d'avoir des scripts d'installation élaborés et on voudrait éviter de les changer pour mettre dedans le nom du schéma même en variable.

Code:

---

BEFORE INSERT StringVariableSchema.TB_REPORT_FAV

---

Quand j'ai fais des tests sur ma plateforme je n'ai eu aucune erreur et ma table TB_REPORT_FAV et son trigger se sont bien crées. Donc je suppose qu'il y a bien un souci au niveau des droits ou de reconnaissance du schéma "MonSchema".

Il n’est pas possible de créer un schéma Oracle sans préciser le nom donc au plus tard à ce moment le schéma n’est plus libre. Du ce point de vue on devrait parler de schéma au nom variable plutôt que libre. Par conséquence vos scripts devrait tout simplement paramétrer le schéma.

Quand vos créez un trigger sur une table Oracle doit être capable de résoudre le nom de la table, c’est à dire de trouver une table ou sinon un synonyme privé ou publique qui correspond. Mais le script a pu tourner sur votre base précisément parce qu'un synonyme avait être crée à un moment donné. Par la suite la table qu’il référence a été supprimée ce qui n’entraîne pas la suppression du synonyme.

J’ai du mal à voir en quoi cette stratégie peut être pratique mais bon.

En SQL, un objet qui n'est pas préfixé par un nom de schéma sera recherché dans le schéma courant.
Si je suis connecté SYSTEM, SYSTEM est par défaut le schéma courant.

L'instruction CREATE TRIGGER, aussi étonnant que cela paraisse, est du SQL (en tout cas jusqu'à DECLARE, ou BEGIN s'il n'y a pas de DECLARE).

Donc si je suis SYSTEM et que j'écris

Code:

---

1 2 3

CREATE TRIGGER nom_trigger ... ON nom_table

---

le déclencheur sera créé dans le schéma SYSTEM et portera sur la table nom_table qui doit se situer dans le schéma SYSTEM. Si cette table n'y est pas, évidemment cela échoue.

Même problème si j'écris

Code:

---

1 2 3

CREATE TRIGGER SCOTT.nom_trigger ... ON nom_table

---

On a bien précisé le propriétaire du déclencheur, mais pas celui de la table, donc celle-ci est toujours recherchée dans le schéma SYSTEM.

Donc plusieurs solutions :

1) se connecter sous le compte qui doit être le propriétaire de la table et du déclencheur, sans préfixer la table ni le déclencheur par le schéma.
Mais ce n'est pas terrible, car cela impose d'être capable de se connecter sous se compte.
Or le DBA, si c'est lui qui exécute ces scripts, n'est pas censé connaître les mots de passe.
De plus, si on ne fait pas attention et qu'on ne s'est pas connecté sous le bon compte, on risque de créer les objets n'importe où.

2) préfixer le nom des objets par le schéma, défini comme variable de substitution. Il suffira de modifier ce DEFINE pour une exécution dans un schéma différent.

Code:

---

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

define SCHEMA=SCOTT   connect system/&MDP   CREATE OR REPLACE TRIGGER &SCHEMA..trigdemo BEFORE INSERT ON &SCHEMA..emp DECLARE num int; BEGIN select count(*) into num from dept; END; /

---

Vous pouvez en revanche remarquer que je n'ai pas préfixé les objets à l'intérieur du déclencheur (à partir du DECLARE).
Par défaut (mode AUTHID DEFINER), ceux-ci seront recherchés dans le schéma dans lequel on crée le déclencheur, ce qui convient dans la plupart des cas.

Merci à tous pour vos réponses.
Je comprends mieux le pourquoi du comment merci encore pour tes explications claires Pomalaix.

J'ai une dernière question : comment connaître le schéma par défaut d'un utilisateur ?

Citation:

---

Envoyé par Daeron

...J'ai une dernière question : comment connaître le schéma par défaut d'un utilisateur ?

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

SYSTEM@DEMO>show user USER est "SYSTEM"   SYSTEM@DEMO>select sys_context('userenv', 'current_schema') AS schema from dual;   SCHEMA --------------- SYSTEM   SYSTEM@DEMO>alter session set current_schema=SCOTT;   Session modifiée.   SYSTEM@DEMO>select sys_context('userenv', 'current_schema') AS schema from dual;   SCHEMA --------------- SCOTT

---

Le schéma courant est tout simplement le schéma de l'utilisateur, sauf si on a l'idée tordue de faire un ALTER SESSION pour le modifier.

Citation:

---

Envoyé par Daeron

Merci pour vos réponses :
@Waldar : Si vous ne voulez pas indiquer le schéma il faut que l'utilisateur avec lequel vous vous connectez pointe sur ce schéma.

Comment faire pour que mon utilisateur "pointe" spécifiquement sur le schéma, je lui donne déjà tous les droits sur ce schéma ?

@Garuda : De quelle vue parlez vous ? ma table TB_REPORT_FAV est une vraie table et non une vue.

---

Effectivement ! Mais l'important dans ma réponse , c'est le fait de créer un synonyme pas l'objet sur lequel il pointe !;)