Discussion :

[claclapub]

Bonjour à tous,

Je crée une procédure avec un curseur.

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
31
CREATE OR REPLACE PROCEDURE Script_chargement_ODS_1Bis IS
 
CURSOR c_table IS
SELECT vsource.view_name, tcible.table_name
FROM SYS.ALL_TABLES tcible,  SYS.ALL_VIEWS vsource
WHERE tcible.OWNER = 'IHR'
and vsource.OWNER = 'IHR'
and tcible.table_name like 'HRA_%'
and tcible.table_name not like 'HRA_ZX%'
and tcible.table_name not like 'HRA_ZY%'
and vsource.view_name like 'ODS_%'
and vsource.view_name not like 'ODS_ZX%'
and vsource.view_name not like 'ODS_ZY%'
and rtrim(substr(tcible.table_name,4,25)) = rtrim(substr(vsource.view_name,4,25))
and tcible.table_name  not in (SELECT substr ( tcible.table_name , 1 , INSTR(tcible.table_name,'TMP',1) - 2 )
FROM SYS.ALL_TABLES tcible
WHERE tcible.table_name like 'HRA_%'
AND tcible.table_name  like '%TMP') ;
 
i c_table%ROWTYPE;
 
BEGIN
FOR i IN c_table
LOOP
EXECUTE IMMEDIATE 'truncate table IHR.' || i.table_name ;
EXECUTE IMMEDIATE 'Insert into IHR.' || i.table_name || ' select * from IHR.' || i.view_name ;
commit;
END LOOP;
 
END;
/

Si je lance l'instruction "select" seule, avec un user "sunopsis", l'instruction me ramène bien des valeurs, provenant de la table SYS.ALL_TABLES.

Par contre, quand je lance la requête, avec le même user "sunopsis", le curseur ne trouve aucune valeur et donc la procédure ne fait rien

Quelqu'un connaitrait une subtilité sur les curseurs qui fasse que celui-ci ne "voit rien" dans la table SYS.ALL_TABLES ?
A noter que cela ne semble pas venir des droits du user "sunopsis". Car dans un autre environnement, de recette, un user identique lance la même procédure avec succés.

Merci d'avance pour votre aide.

[brassouille]

Bonjour,

je viens de lancer ce code chez moi :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
  PROCEDURE testt IS
    CURSOR curseur IS 
      SELECT vsource.view_name, tcible.table_name
      FROM SYS.ALL_TABLES tcible,  SYS.ALL_VIEWS vsource;
  BEGIN
    FOR ligne IN curseur LOOP
      raise_application_error(-20333, ligne.view_name || ' ' || ligne.table_name);
    END LOOP;
  END;

(ouais ok c'est bourrin )
et l'exception est bien lancée, preuve que le curseur a retourné au moins une ligne et donc qu'il est capable de lire dans les tables en question...
Tu peux essayer chez toi?
Pour info tu n'as pas besoin de déclarer ta variable "i"

[brassouille]

Car dans un autre environnement, de recette, un user identique lance la même procédure avec succés.

Tu veux dire qu'il arrive à lancer la procédure que tu as écrite avec le curseur? Dans ce cas le problème ne peut pas venir du fait d'utiliser un curseur...
Peut-être que quand tu exécutes un select, et quand tu exécutes une procédure stockée (indépendamment d'utiliser ou non un curseur), tu n'as pas les mêmes droits... mais là je saurai pas t'aider

[claclapub]

Bonjour,
je viens de lancer ce code chez moi :
et l'exception est bien lancée, preuve que le curseur a retourné au moins une ligne et donc qu'il est capable de lire dans les tables en question...
Tu peux essayer chez toi?
Pour info tu n'as pas besoin de déclarer ta variable "i"

Bonjour et d'avance merci pour ton aide.

J'ai créé la procédure puis je la lance l'instruction dans TOAD :

Code :

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

1
2
3
begin
SUNOPSIS.DIDIER_TEST() ;
end ;

Tout s'est bien passé.
Mais comment savoir si le curseur a ramené quelquechose avec son select ?

[claclapub]

Tu veux dire qu'il arrive à lancer la procédure que tu as écrite avec le curseur?(

Exact, la procédure est bien lancée mais ne dure que 2 secondes, comme si le curseur ne faisait rien.

[brassouille]

Tout s'est bien passé.
Mais comment savoir si le curseur a ramené quelquechose avec son select ?

En fait si au moins une ligne du curseur est lue, ça doit te lancer une exception en écrivant les premières valeurs lues (oui j'ai fait bourrin ).

Essaye plutôt avec ça, comme ça ça t'affichera si une ligne est retournée ou non :

Code :

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

1
2
3
4
5
6
7
8
9
10
PROCEDURE DIDIER_TEST IS
    CURSOR curseur IS 
      SELECT vsource.view_name, tcible.table_name
      FROM SYS.ALL_TABLES tcible,  SYS.ALL_VIEWS vsource;
  BEGIN
    FOR ligne IN curseur LOOP
      raise_application_error(-20333, 'Au moins une ligne retournee : ' || ligne.view_name || ' ' || ligne.table_name);
    END LOOP;
    raise_application_error(-20334, 'Aucune ligne retournee');
  END;

Dis moi ce que ça t'affiche comme message.

[claclapub]

Essaye plutôt avec ça, comme ça ça t'affichera si une ligne est retournée ou non :

En effet, je peux mieux analyser le truc, merci.

Et bien effectivement, la procédure en recette ramène "au moins une ligne" en REC, mais elle ne ramène rien en PROD.

Pourtant, le SQL lancé seul en PROD fonctionne correctement et me ramène des lignes...

[brassouille]

Essaye de faire en PROD :

- d'une part en ligne de commande un "select * from user_users" et regarde le username

- d'autre part execute cette procedure stockée :

Code :

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

1
2
3
4
5
6
7
8
PROCEDURE DIDIER_TEST IS
    CURSOR curseur IS 
      select * from user_users;
  BEGIN
    FOR ligne IN curseur LOOP
      raise_application_error(-20333, 'Utilisateur : ' || ligne.username);
    END LOOP;
  END;

Est-ce que les deux utilisateurs sont bien identiques?

[skuatamad]

Peut-être que quand tu exécutes un select, et quand tu exécutes une procédure stockée (indépendamment d'utiliser ou non un curseur), tu n'as pas les mêmes droits

Oui, les procédures stockées ne connaissent pas les droits données via un rôle.
Il faut donner les droits directement à l'utilisateur.

Qu'est ce que ça donne dans un bloc anonyme sous sqlplus?

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
set serverout on
 
DECLARE
CURSOR c_table IS
SELECT vsource.view_name, tcible.table_name
FROM SYS.ALL_TABLES tcible,  SYS.ALL_VIEWS vsource
WHERE tcible.OWNER = 'IHR'
AND vsource.OWNER = 'IHR'
AND tcible.table_name LIKE 'HRA_%'
AND tcible.table_name NOT LIKE 'HRA_ZX%'
AND tcible.table_name NOT LIKE 'HRA_ZY%'
AND vsource.view_name LIKE 'ODS_%'
AND vsource.view_name NOT LIKE 'ODS_ZX%'
AND vsource.view_name NOT LIKE 'ODS_ZY%'
AND rtrim(substr(tcible.table_name,4,25)) = rtrim(substr(vsource.view_name,4,25))
AND tcible.table_name  NOT IN (SELECT substr ( tcible.table_name , 1 , INSTR(tcible.table_name,'TMP',1) - 2 )
FROM SYS.ALL_TABLES tcible
WHERE tcible.table_name LIKE 'HRA_%'
AND tcible.table_name  LIKE '%TMP') ;
BEGIN
FOR i IN c_table
LOOP
dbms_output.put_line(i.view_name||' - '||i.table_name);
END LOOP;
END;
/

[claclapub]

Oui, les procédures stockées ne connaissent pas les droits données via un rôle.
Il faut donner les droits directement à l'utilisateur.

BINGO dans le mille !
Mon problème est résolu.
Merci à tous pour votre aide et votre rapidité, je suis époustouflé