Discussion :

[Daeron]

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 :

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
 
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 !

[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.

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 :

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

:NEW.REPORT_FAV_SN := SEQ_TB_REPORT_FAV.NEXTVAL;

[Garuda]

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

[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.

[mnitu]

Enlevez

Code :

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

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.

[mnitu]

...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 ?

[Daeron]

@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.

[mnitu]

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

[Pomalaix]

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

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

[Daeron]

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 :

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

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".

[mnitu]

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.

[Pomalaix]

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 :

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

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 :

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

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 :

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

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.

[Daeron]

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 ?

[Pomalaix]

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

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
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.

[Garuda]

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 !