Problème curseur - select vide

Bonjour à tous,

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

Code:

---

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.

Bonjour,

je viens de lancer ce code chez moi :

Code:

---

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"

Citation:

---

Envoyé par claclapub

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 :(

Citation:

---

Envoyé par brassouille

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:

---

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 ?

Citation:

---

Envoyé par brassouille

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.

Citation:

---

Envoyé par claclapub

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:

---

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.

Citation:

---

Envoyé par brassouille

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

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:

---

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?

Citation:

---

Envoyé par brassouille

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:

---

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; /

---

Citation:

---

Envoyé par skuatamad

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 :king: dans le mille !
Mon problème est résolu.
Merci à tous pour votre aide et votre rapidité, je suis époustouflé :D