Appel une procédure d'une autre procédure

Bonjour,

J'ai un package dans la quelle, j'ai écrit 2 procédures stockées:

Code:

---

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

Procedure P1 IS Begin --Appel une autre procédure Procedure 2 (1); End P1   Procedure P2 (a in number) IS Begin body P2.... End P2

---

Le problème est que quand je compile, il affiche pas d'erreurs et quand j'éxecute, il affiche:
ORA-04063: package body "sss" comporte des erreurs
ORA-06508: PL/SQL : unité de programme nommée : "sss" introuvable
ORA-06512: à ligne 10

Par contre, si j'écris le suivant, j'ai pas de problème:

Code:

---

1 2 3 4 5 6

Procedure P1 IS Begin body P2 End P1

---

Ce que je constate est qu'il y a un pb avec l'appel de la P2, ce que je ne comprends pas car quand j'écris directement le code dans la P1, cela fonctionne.

Merci d'avance

le package specification contient bien les 2 ? Ce serait plus simple avec un vrai exemple :?

La "compilation" du package body travaille en séquentiel.
--> premiere procedure trouvée = P1 qui contient un appel à P2 avec P2 un objet inconnu puisque le "compilateur" n'est pas encore "passé" sur P2 (qui se trouve après P1).

Solution : inverser la définition, c'est-à-dire
Procedure P2 (a IN number)
IS
Begin
body P2....
End P2

Procedure P1
IS
Begin
--Appel une autre procédure
Procedure 2 (1);
End P1

plalm a raison et c'est même une "erreur" typique de tout langage mais pas seulement pl/sql => juste permuter les places des fonctions, la fonction à utiliser dans l'autre en premier

J'en profite pour demander aussi si on peut faire de la récursivité avec les procédures et fonctions PL/SQL ?

Sauf que la déclaration différenciée des headers et body permet gérer ce cas de figure....

Oui mais en la mettant dans le header, on la rend aussi publique non ? Ce qui n'est pas forcément ce que l'on veut.

Sinon pour répondre à randriano, oui on peut faire de la récursivité y compris sur une procédure/fonction qui n'est pas déclarée dans le header. Ainsi, une procédure peut s'appeler elle-même sans déclaration dans le header mais deux procédures qui s'appellent entre elles doivent être déclarée (ou au moins la deuxième dans le code) .

Citation:

---

Envoyé par Korfandar

Oui mais en la mettant dans le header, on la rend aussi publique non ? Ce qui n'est pas forcément ce que l'on veut.

---

Oui je m'étais aussi confronté à ce problème...

Vicenzo a raison - la declaration est différencie - et cela n'a rien avoir avec le fait que la function/procedure soit public.

Un petit exemple valant toujours mieux qu'un long discour ... avec
+ une function public qui affiche la surface d'un cercle
+ une function privée qui effectue la multiplication nécessaire

Citation:

---

create or replace package test_pkg as

-- 'SIGNATURE PUBLIQUE' DES FUNCTIONS ET PROCEDURES
function Tst01 (pRayon in number) return varchar2;

end test_pkg;
/

create or replace package body test_pkg as

-- 'SIGNATURE PRIVEE' DES FUNCTIONS ET PROCEDURES
function Tst02 (pValue in number) return number;

-- DEFINITION PREALABLE DES CONSTANTS
cPi NUMBER := 3.14 ;

-- DEFINITION DE Tst01
-- L'ordre n'a plus d'importance la signature en debut
-- de package body. Ici, Tst02 est connu
function Tst01 (pRayon in number) return varchar2 is
begin
return 'La surface du cercle de rayon ' || pRayon || ' vaut ' || Tst02(pRayon);
end Tst01;

-- DEFINITION DE Tst02
-- Il s'agit d'une definition stritement privee valide
-- uniquement au sein de ce package body
function Tst02 (pValue in number) return number is
begin
return cPi * power(pValue,2);
end Tst02;

end test_pkg;
/

---

En l'absence de la signature privée de la function Tst02, le package body est en erreur (c'est la question posée dans cette discussion).

Dans l'exemple, la définition de Tst02 se fait uniquement dans le package body --> Tst02 n'est donc pas public ; la peuve

Citation:

---

SQL> desc test_pkg
FUNCTION TST01 RETURNS VARCHAR2
Argument Name Type In/Out Default?
------------------------------ ----------------------- ------ --------
PRAYON NUMBER IN

---

Ha d'accord, je n'avais pas du tout compris ce dont parlait Vicenzo. Merci pour ce cours, j'avais complètement zappé cette possibilité :D

plalm ! Peux-tu m'expliquer le truc de public/private en PL/SQL ?
Le package n'est-il pas qu'une structure pour contenir des variables, des fonctions et des procédures mais pas comme une classe en P.O.O ?

Citation:

---

Envoyé par bruce-willis

plalm ! Peux-tu m'expliquer le truc de public/private en PL/SQL ?
Le package n'est-il pas qu'une structure pour contenir des variables, des fonctions et des procédures mais pas comme une classe en P.O.O ?

---

Le package est constitué de deux parts dépendantes :

1. le package qui contient la définition des functions/procedures qui pourront être exécutées directement ou appelée au sein d'un autre package par le owner lui-même (ou par un autre user - après nécessairement un GRANT EXECUTE). A cet endroit, la définition se limite à
   
   • donner un nom à la function/procedure
   
   
   • énumérer les paramètres utilisés avec leurs caractéristiques (nom, IN/OUT, type , valeur par défaut)
   
   En aucun cas, il n'y a ici l'indication de ce qui est réalisé (ni du comment) par la function/procedure - sauf via un éventuel commentaire (best practice) ; ceci doit être réalisé dans le package body.
   Par contre, le contenu du package peut être utilisé par les users qui possèdent le privilege execute sur le package : je les qualifie de public

1. le package body qui contient
   
   • le code de chaque function/procedure définie dans le package
   
   
   • le code de toute autre function/procedure qui serait jugée utile par le développeur - c'est le cas de Tst02 dans mon exemple. Les functions/procedures ici définies ne peuvent être invoquées qu'au sein de ce seul package body ; je les qualifie de private

La qualité de public/pivate est donc basée sur la portée de la dite function/procedure ... cela ne vous rappele-t-il pas quelque chose ?

==> Le package n'est pas qu'une structure de stockage des functions/procedures ; il facilite grandement la gestion de la sécurité.

Ah je comprends, le fait de déclarer Tst02 seulement dans package body le considère comme privé, utilisable seulement dans le package !
Rien avoir avec la Programmation Orientée Objet don !!! :mouarf:

Citation:

---

Envoyé par bruce-willis

Ah je comprends, le fait de déclarer Tst02 seulement dans package body le considère comme privé, utilisable seulement dans le package !
Rien avoir avec la Programmation Orientée Objet don !!! :mouarf:

---

Heu non rien à voir ! Il faut dire que la devise "Pensez objet, pensez Oracle" ne constitue pas non plus mon fond d'écran.

Au plaisir.

Bonsoir,
Moi je dirais au contraire que oui.
Private et public ont la meme signification en java et en pl par exemple.
Variable privée est en quelque sorte une variable locale au package ou à l'objet. Pour la manipuler depuis l'exterieur on peut utiliser une fonction public( getter et setter concept des beans)
variable publique n'importe qui peut modifier la valeur de cette variable.

C'est essentiel pour garantir la valeur d'une variable
Cdt

Sauf qu'à mon sens, manquent l'héritage et le polymorphisme !
.

Citation:

---

Envoyé par plalm

La qualité de public/pivate est donc basée sur la portée de la dite function/procedure ... cela ne vous rappelle-t-il pas quelque chose ?

---

Lorsque j'ai écrit cela, c'était un clin d'oeil au langage C (d'autres aussi) qui gère de manière similaire la portée des variables. Est-ce que C est OO ? Cette qualité est-elle suffisante pour définir un langage OO ?

Il manquerait alors quelque chose pour accéder au titre de langage objet ? Star a déjà répondu à cette dernière énigme.

OK plalm !!! :oops: