recompilation automatique des objets invalides

**GMI3** · 02/12/2007, 13h55

bonjour,

Depuis que j'utilise la 10g, la recompilation automatique des objets automatique se comporte différemment. Désormais, les sessions qui étaient ouvertes lors de la compilation d'un package doivent sortir complètement de leur session pour en ouvrir une nouvelle

.

Sur les précédentes versions d'oracle, il suffisait de valider le message indiquant que l'objet était invalide, et la recompilation n'imposait pas de sortir de sa session.

Est-ce que la base que j'utilise a une configuration particulière ?
ou est-ce la 10g qui impose cela ?

Merci d'avance pour vos réponses

**Vincent Rogier** · 02/12/2007, 14h52

Si la compilation touche au body (modification de prototypes de fonctions) et/ou variables du package, tu auras forcement lors du prochain appel au package une erreur car l'instance de ton package au sein de ta session est devenue invalide, cela quelque soit la version du serveur.

**Garuda** · 03/12/2007, 16h56

Je corrige

Si la compilation touche au body (modification de prototypes de fonctions) et/ou variables du package

En fait c'est si tu modifies les SPEC (prototype) que les objets référencées par le package sont invalidés.
Si tu touche au "body" (??), il ne se passe rien.

**Vincent Rogier** · 03/12/2007, 17h12

Effectivement, mon clavier a fourché !

C'est bien aux spécifications de packages et non aux corps de packages auxquelles je faisais référence !

Désolé si j'ai induis certains en erreur !

**pifor** · 03/12/2007, 18h30

Je confirme que si package contient une variable de session, il y a erreur en 9i ou en 10g même si la spec. du package n'est pas modifiée. Voir les scénarios que j'ai posté sur OTN.

**GMI3** · 05/12/2007, 21h18

Merci pour vos infos.
Je vais y perdre énormément en terme de souplesse. Tous mes packages ont une variable globale qui précise le nom du package lui-même.

Y a-t-il une solution pour éviter ce mode ?
C'est très lourd pour les modifs en "live"

**Garuda** · 06/12/2007, 09h22

- Faire un variable "privée" (cad non déclarée dans les spec) : ex NomProc
- Faire une fonction "publique" (cad déclarée dans les specs) qui te retourne la valeur de cette variable (ex : GetNomProc )
Tu pourras ainsi modifier la valeur de cette variable sans changer le statut des specs
Au fait, pourquoi dans ton cas ne pas faire une constante ?