Package Dans un schema maitre executé par un schema Esclave

j'ai souhaite faire evoluer mon soft en créant un schema "Moteur d'application" (maitre) dans lequel je veux declarer toutes mes fonctions , procedures & packages afin d'eviter de redeclarer "n" fois le meme "package/fonction/procedure" dans chaque schema (c'est le cas aujourd'hui)

j'ai "n" schema (memes tables mais données différentes) "User" (Esclave) pouvant executer l'ensemble des "fonctions / procedures / packages " du moteur d'aplication ==> "Grant Execute On ...... to Mes "n Schema "

Problème sur le moteur : lorsque je vais compiler (entre autre) un package : ORACLE va me renvoyer dans mes Buts en me disant que la table "Truc" et "Machin" n'existent pas dans le schema "Moteur"


Est-ce que je me fait bien comprendre ?

C'est possible de faire ce que je souhaite ?

c'est évidemment le owner qui compile ... mais où est le problème ?

je vais formuler différement ma demande :

Exemple : dans les 4 schemas suivants : sch1,sch2,sch3,sch4 j'ai la meme table "tab_test" avec un nombre d'enreg différents dans chaque schema

comment faire une fonction "generique" pouvant etre lancé de n'importe quel schema qui me ramene le nombre d'enregistrement de "tab_test"

Code:

---

1 2 3 4 5 6 7 8

create or replace function nb_test return number is a number; Begin Select count(*) into a from tab_test; return(a); End; /

---

Pour Exemple :
Je compile cette fonction connecté sur le schema "sch4"
avec un public synonym sur la fonction . :?

Maintenant , connecté sur sch1 : :!:
si je fait un

Code:

---

select nb_test from dual

---

le nombre renvoyé est le nombre d'enreg de sch4.tab_test :twisted:

alors que le resultat souhaité est le nombre d'enreg de sch1.tab_test

Est-ce possible de faire cela (sans avoir à generer la fonction dans chque schema) ? :?:

Il faut déclarer vos procédures de package avec la clause :

Code:

---

AUTHID CURRENT_USER

---

pour qu'elles utilisent les tables du user qui exécute et non celles du user propriétaire du package

Trop fort votre majesté !!! :lol: :lol: :lol: :lol:
8) 8) 8) 8)

Par contre : juste une autre question : il faut tout de meme créé des tables à l'identique (vide) sur mon schema "maitre" afin que la compile des package ne plante pas :?: :?:

Citation:

---

Envoyé par argoet

Par contre : juste une autre question : il faut tout de meme créé des tables à l'identique (vide) sur mon schema "maitre" afin que la compile des package ne plante pas :?: :?:

---

Tout juste, ou peut-être utiliser des synonymes qui pointent sur les tables d'un de vos users...

faire néanmoins attention à ne pas donner les droits sur les objets via des roles !

:twisted:

J'ai décocher le résolu : :twisted: :twisted:
Il peut exister un vrai pb lorsque l'odre des colonnes d'un schema à l'autre differe.


Je m'explique.
J'ai compilé mon package sur le schema maitre : OK pas de Pb
Par contre lors de l'execution sur un autre schéma ==> Plantage (Invalid number) et pourtant en testant manuellement le package tous semblait correct ..... et pourtant ........

Code:

---

1 2 3 4 5

Dans mon schéma maitre : la table TAB1 est composé des colonnes suivantes Number_truc number, Char_machin varchar2(10), Number_chose number

---

Code:

---

1 2 3 4 5

Dans mon schéma d'execution : la table TAB1 est composé des colonnes suivantes Char_machin varchar2(10), Number_truc number, Number_chose number

---

Vous voyez la différence : ? Truc est avant machin et dans l'autre machin est avant truc !!!

Code:

---

1 2 3 4 5 6 7 8 9 10

Dans le package compilé sur le schéma maitre j'ai ce qui suit : Declare Row_Tab1 TAB1%ROWTYPE; Begin Select * into Row_Tab1 from TAB1 Where ............       End;

---

à l'execution cela donne ceci (Un Varchar2 envoyé dans une Variable de type Number) ==> ORA-01722 Invalid Number

J'ai eu la chance d'avoir ce genre d'erreur car si les colonnes avait été de meme type, je ne vous explique pas le Problème pour trouver l'origine du Pb

Et l'idée première qui consiste à remplacer le * par la liste explicite des colonnes, ça donne quoi ?

Code:

---

1 2 3 4 5 6 7

Select * into Row_Tab1 from TAB1 Where ............ --> Select char_machin, number_truc, number_chose into Row_Tab1 from TAB1 Where ............

---

Pomalaix a raison.

Evitez le Select * ...
ainsi que l'insert sans la liste des colonnes.

Citation:

---

Envoyé par Pomalaix

Et l'idée première qui consiste à remplacer le * par la liste explicite des colonnes, ça donne quoi ?

Code:

---

1 2 3 4 5 6 7

Select * into Row_Tab1 from TAB1 Where ............ --> Select char_machin, number_truc, number_chose into Row_Tab1 from TAB1 Where ............

---

---

Ben comme je le pensait "Seul le select *" est valable avec une variable Row de type TABLE .

Cela ne resout en rien le Pb

Hum ! a bien y regarder, il semble que ce ne soit pas un problème d'insert, mais tout simplement de colonnes qui ne sont pas définies de la même façon dans les tables des différents schémas.

COLIS CARTON%ROWTYPE;
Avant

Code:

---

1 2 3

Select * into COLIS from CARTON C Where C.Soc_no = SOC_soc_no And C.col_nfac = CARTON_col_nfac;

---

Après (j'ai volontairement modifié l'odre des colonne pour valider ce test)

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

Select C.col_qual, C.col_fpos, C.col_redg, C.col_redc, C.col_sign, C.col_mttd, C.col_mfac, C.col_pai1, C.col_sdun, C.col_cmat, C.col_cfac, C.col_cfil, C.col_empb, C.col_embt, C.col_poid, C.col_dexp, C.col_cvac, C.col_cgou, C.col_csac, C.col_lang, C.col_iaff, C.col_mpai1, C.col_mpai2, C.col_orig, C.edi_code, C.col_supt, C.col_ifpr, C.col_cled, C.col_srel, C.col_plan, C.col_echp, C.col_mtav, C.col_noav, C.col_tax1, C.col_clet, C.col_mprt, C.col_ftrt, C.col_curg, C.col_nptt, C.col_cgiro, C.col_sgiro, C.col_nchif, C.col_chol, C.soc_no, C.col_nfac, C.lot_numo, C.cha_code, C.rgp_code, C.stc_code, C.cnf_num, C.col_ncli, C.col_numo, C.col_expc, C.col_dfac, C.col_bdx, C.col_type, C.col_fprt, C.col_crt, C.col_tpai, C.col_mexp, C.col_sdis, C.col_sexp, C.col_texp, C.col_irap, C.col_ilent, C.col_icirc, C.col_iqte, C.col_iqva, C.col_char, C.col_numf, C.col_cont, C.col_ncol, C.col_slot, C.col_bqec, C.col_dval, C.col_cpd, C.col_idv, C.col_tax2, C.col_fiav, C.col_fiut, C.col_fiat, C.col_ztar, C.col_npat, C.col_cdis, C.col_cdep, C.col_ndep, C.col_prfx, C.col_ncou, C.col_prel, C.col_cppr, C.col_idis, C.col_mail, C.col_mailr, C.pal_num, C.tps_code, C.col_ipoid, C.col_iprev, C.res_code into COLIS from CARTON C Where C.Soc_no = SOC_soc_no And C.col_nfac = CARTON_col_nfac;

---

PL/SQL: ORA-00932: inconsistent datatypes: expected DATE got
NUMBER

Citation:

---

Envoyé par SheikYerbouti

Hum ! a bien y regarder, il semble que ce ne soit pas un problème d'insert, mais tout simplement de colonnes qui ne sont pas définies de la même façon dans les tables des différents schémas.

---

:oops: :oops:
Ben c'est ce que je me tu a vous dire depuis que j'ai réouvert ce post

Skusez moi si jme suis pas bien fait comprendre

Oui, donc vous devez vérifier la structure de vos 2 tables champ par champ

Citation:

---

Envoyé par Marc Musette

faire néanmoins attention à ne pas donner les droits sur les objets via des roles !

---

En relisant cette enfilade suite à la question d'aujourd'hui, je me disais que c'était une mise en garde fort pertinente.

Eh bien la doc vient de m'apprendre que les rôles peuvent s'appliquer dans une procédure/fonction définie en AUTHID CURRENT_USER !!

Using Roles with Invoker-Rights Subprograms

The use of roles in a subprogram depends on whether it executes with definer rights or invoker rights.
Within a definer-rights subprogram, all roles are disabled. Roles are not used for privilege checking, and you cannot set roles.

Within an invoker-rights subprogram, roles are enabled (unless the subprogram was called directly or indirectly by a definer-rights subprogram). Roles are used for privilege checking, and you can use native dynamic SQL to set roles for the session. However, you cannot use roles to grant privileges on template objects because roles apply at run time, not at compile time.