🚀 go-pugleaf

On 10 Lip, 09:39, Maseł <mma...@poczta.onet.pl> wrote:

> A mozesz naszkicowac taki prayklad (pseudokod, nie koniecznie prawdziwe
> nazwy pakietow...) - bo wydaje mi sie, ze na razie nie do konca rozumiem
> opis problemu.

W dużym uproszczeniu:

Create or replace package PakietA
   A integer default 0;

  function getA return integer;
  procedure iniZmiennePakietowe;
....
end;

Create or replace package body PakietA
....
function getA return integer
  begin
     return nvl(A,0);
end;

procedure iniZmiennePakietowe is
  begin
     A := 1;
  end;
begin
  iniZmiennePakietowe;
end;

oraz osobna funkcja (nie w pakiecie)
create or relace function sprawdzA return integer is
begin
   return PakietA.getA;
end;

Tak więc w normalnych warunkach po zalogowaniu jesteśmy w sesji XXX.
Próba odwołania
select SprawdzA from dual;
zwróci 1 bo najpierw pakiet załaduje się do pamieci czyli odpali
iniZmiennePakietowe, która ustawi A na 1.

Jeśli jednak jesteśmy zalogowani dalej w sesji XXX i pakiet już jest w
pamieci i teraz z innej sesji Oracle zmienimy coś i przekompilujemy
specyfikację pakietu A to
select SprawdzA from dual;
zwróci 0.
ale
select PakietA.getA from dual;
zwróci 1 po uprzednim zgłoszeniu błędu o przestarzałej wersji pakietu
A i ponownym wykonaniu

Wniosek z tego taki, że wszystkie niezależne procedury mogące
odwoływać się do zmiennycm pakietowych powinny się znaleźć w pakiecie,
który ma sekcję ininicjalizującą te zmienne pakietowe.
Tak właśnie zrobiłem.
Muszę tylko jeszcze sprawdzić jak będą zachowywać się triggery
używające takich zmiennych.